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WORKFLOW MANAGEMENT SYSTEM AND METHOD 

BACKGROUND OF THE INVENTION 

1. Field of technology 

The present invention relates to computerized workflow management and 
5 operational support for persons engaged in complex business or other processes. It has 

particular utility in supporting operations by financial organizations serving as trustees 
for securitizations, i.e., financial instruments such as Mortgage-Backed Securities 
(MBS), and other Asset-Backed Securities (ABS) or other financing arrangements 
involving debt instruments for which periodic valuation and distribution computations, 

1 0 disbursements and reporting must be set up and executed. 

Securitization is commonly defined as a pooling of assets and issuance of 
securities to finance the carrying of the pooled assets. This process allows 
understanding of the behavior of a class of assets as a whole to be employed in creating 
a financial structure to finance such assets without the need to be concerned about the 

15 behavior of the specific asset within the class. (See Kravitt, Securitization, The 

Financier, Vol. 4 5 No. 5, December 1997.) The actual securitization process involves 
issuance of bonds which are backed, not by capital assets of the issuer, but rather by the 
cash flow from the pooled assets. These may be residential or commercial mortgages, 
credit card receivables, equipment leasing or even student loans, etc. 

2 0 For a securitization to be an attractive investment vehicle, it must be carefully 

structured, for example, to take into account factors such early payoff of loans by 
mortgage holders. This often results in a very complex financial instrument, and 
correspondingly complex processing is required to manage the transaction. 

Each of the participants in a securitization transaction serves a different role. For 

2 5 example, in the case of a residential MBS, the participants might include the originating 

mortgage lender, the issuer of the MBS (which could be the lender or a third party which 
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employed, and reduction of the number of platforms (and consequent need for 
maintenance) required for the universe of processing and reporting tasks; 
to unify the required operations and processing tasks thereby improving 
efficiency, and insuring consistency of results for these various participants in 
the transactions; 

to improve quality control environment for periodic processing and auditing 
integrity; 

to provide a scalable system which allows growth of the number of projects 
which can be handled without addition to the cost structure, along with 
improved reporting (e.g., via the Internet, E-mail, etc), and provision of 
technical links (e.g. interfacing between pre-existing sub-system) to reduce 
manual work; 

to provide the capability for handling presently existing securitization structures 
and the flexibility to handle new types of structures and new collateral 
(securities) types, both nationally and globally, through convenient modification 
of data structures; 

to allow effective use of the Internet and the World Wide Web for deal 
reporting; 

to provide improved workflow management capabilities for the performance of 
the complex analytical and other activities which are characteristic of 
securitization transactions; 

to provide for graphical representation of the performance of the securities and 
underlying collateral; 

to permit online updates of deal performance projections based on "what if 
scenarios; and 

to allow creation of dynamic customized reporting formats based on user inputs. 



-5- 

The above-stated objectives are achieved in accordance with this invention on 
a computer network organized on a client-server model. Broadly stated, the software 
is implemented on a relational database management system ("RDBMS"), and is 
comprised of a command processor, workflow management software and a Workflow 
5 Database. The actual data-processing is carried out by several independent subsystems 
each implemented on an RDBMS, and which interface with, and are controlled by, the 
workflow management system. 

Utilizing the programming capabilities of the RDBMS, forms are made available 
to the users for manually entering data, for generating data search queries, and for 
10 displaying data returned by the queries or created as a result of the various processing 

functions. The system also makes available to the user, a listing of the active deals for 
which he or she is responsible. The listing displays the status of each deal and thus 
serves both as a to - do list, and as a menu from which tasks to be performed may be 
initiated. 

1 5 The system is designed to permit convenient editing of data by the users, as well 

as updating of the underlying database structures by a database administrator. The 
system also permits dissemination of reports both in print and electronically. Further, 
the system permits development and utilization of a wide range of verification or quality 
control tests by which the integrity of incoming data and computational output may be 

2 0 evaluated. 

Another important aspect of the invention resides in the method of workflow 
management which may be performed using the above described system. Briefly, the 
method involves creating an underlying database structure for recording the processing 
steps and other information required for each deal, entering the necessary setup 

2 5 information by selection from lists of pre-stored information about processing functions, 

the associated workflow events (referred to herein as "queues") and status milestones 
for the queues, mapping the data structures of the subsystem databases and the workflow 
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management database to provide transparent interfacing and convenient manual entry 
of data were necessary, displaying for the user the queue and milestones status of all the 
deals for which he or she is responsible, permitting menu driven initiation of the tasks 
required in each queue each the deals and automatically updating the database records 
5 for the universe of deals being managed by the system. 

Another feature of the method according to this invention involves development 
by the user of verification tests from pre-existing lists of variables and parameters, from 
manually selected parameter values and a listing of mathematical operators, and the 
association of the verification tests with the deals to which they are applicable. 
10 Other features and advantages of the present invention will become apparent 

from the following description of the invention which refers to the accompanying 
drawings, in which like functional units, processing steps, etc. bear like reference 
numerals. 

BRIEF DESCRIPTION OF THE DRAWINGS 
15 FIG. 1 is a conceptual overview of the life cycle of a new securitization or 

"dear 1 . 

FIG. 2 illustrates the processing and reporting infrastructure according to the 
prior art. 

FIG. 3 illustrates the processing and reporting infrastructure according to the 
2 0 present invention, 

FIG. 4 illustrates in block diagram form, the architecture of the workflow 
management system according to the present invention. 

FIG. 5 A is a schematic illustration of the functional features of certain of the life- 
cycle stages illustrated in FIG. 1 . 
2 5 FIG. 5B broadly illustrates the workflow sequences for the functions managed 

in accordance with the present invention. 
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FIGS. 5C and 5D respectively illustrate the queue structures for waterfall and tax 
processing. 

FIGS. 5E through 5K illustrates the database structure by which the present 
invention is implemented. 
5 FIG. 6 shows an example of a Main Menu in accordance with the invention. 

FIGS. 7A though 7H illustrate examples of data input screens for deal setup. 
FIG. 8 illustrates an example of a data entry screen for index Rate information. 
FIG. 9 illustrates an example of a data entry screen for making changes to staff 
assignments for more than one deal had time. 
1 0 FIG. 1 0 is an example of a entry screen for assigning privilege levels to system 

users. 

FIG. 1 1 illustrates an example of a work flow screen according to the invention 
which provides task prompting and selection capability for users of the system. 

FIGS. 12A through 12D illustrate examples of user screens associated with 
1 5 various processing operations. 

FIGS. 13 A through 13D illustrate examples of user screens specifically 
associated with the processing of periodic investor distribution payments. 

FIG. 14 illustrates an example of the user screen for selecting specific tax reports 
to be generated. 

2 0 FIGS. 15A through 15D illustrate examples of user screens for development of 

automated verification tests, parameter value selection, and association of the 
verifications developed with specific deals. 

FIG. 16 illustrates an example of a screen from which the user may initiate 
automated verifications. 
2 5 FIG. 17 illustrates an example of a verification report. 

FIGS. 1 8 A through 1 8D illustrate examples of screens from which the user can 
initiate and manage the restatement process for a particular waterfall distribution. 
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Throughout the drawings, like functional units, processing steps, etc. bear like 
reference numerals. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT OF THE INVENTION 
5 To provide an understanding of a particular environment in which the present 

invention may be used, FIG. 1 illustrates the life cycle of a typical securitization from 
the viewpoint of the trustee. The life cycle begins with an Identification phase 100, in 
which a new deal first comes to the attention of the trustee. Then follows Proposal 
phase 105, in which a written proposal is prepared and submitted to the underwriter, a 

10 Deal Modeling phase 110, in which the underlying contract for the transaction is 

analyzed by the trustee to set up a deal model for the required monthly waterfall and tax 
calculations and reporting, and for the associated workflow, the Setup phase 115, in 
which the monthly processing steps for computations related to the waterfall and tax 
processing are specified and implemented in the software by the analyst, the Waterfall 

15 Processing phase 120, in which the monthly waterfall calculations are performed, the 

Monthly Payment and Reporting phase 125, in which the monthly investor payments 
are made and the investor reports are generated and disseminated, the Tax Processing 
phase 130, the Tax Reporting phase 135 and the Payoff phase 140, in which the bonds 
are redeemed. It should be understood that life cycle phases 1 00, 1 05, 1 1 0, 1 1 5 and 140 

2 0 illustrated in FIG. 1 are one-time events, while phases 120, 125, 130 and 135 are 

repetitive events which may be thought of as part of a larger Processing, Disbursement 
and Reporting phase 145 shown in broken lines in FIG. L 

FIG. 2 illustrates the infrastructure for processing a typical mortgage backed 
security deal according to the prior art. For simplicity, it is assumed that a single loan 

2 5 servicer 150, such as a mortgagee or a successor to which a portfolio of mortgages has 

been assigned, is responsible for monthly collection of mortgage payments, and 
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transmittal to the trastee of funds and loan level data, i.e., information concerning 
principal, interest payments and balances on the individual loans, payment and 
delinquency history for the individual loans, loan payoffs, etc. However, it is possible 
for more than one servicer 150 may be involved in a particular deal. 
5 Funds and loan level data are transmitted at step 155 to the trustee for loan 

remittance processing at step 160. This involves tabulation and summarization of the 
loan level information on an aggregate basis for further processing. This is commonly 
done using software designed for that specific purpose. 

Referring still to FIG. 2, the next phase of the operation according to prior 

1 0 practices was monthly waterfall and tax processing. To support this, the aggregated loan 

remittance data and any other required data from the loan servicer was manually entered 
(steps 165 and 170) into computers running the applications by which the necessary 
calculations were performed (step 175). These applications often did not run under a 
single operating system and were of a broad range of vintages with correspondingly 

1 5 diverse capabilities. There was little or no interoperability or interfacing between these 

applications. 

In the absence of effective integration, the resulting computations were printed 
out (step 180) and delivered by hand for review by the deal administrator (step 185). 
Again, because of interoperability problems, after approval, the printed computations 

2 0 were hand delivered (step 190) and manually entered into a separate payment system 

(step 195). After further processing, the payments and backup data were sent by mail 
and facsimile to the individual investors (step 200). Finally, the payment data were 
manually entered into the tax model (step 205). 

In contrast, as illustrated in FIG. 3, according to the present invention, loan level 

2 5 data transmitted from the loan servicer(s) 1 50 at step 1 5 5 is aggregated at step 1 60' by 

a Loan Remittance Processing System ("LRPS"), and transmitted electronically at step 
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165' to Workflow Manager 210. This performs the required waterfall and tax 
processing, review, approval and verification (quality control)functions, and report 
generation and performs all the required workflow management functions. 

Waterfall data produced by Workflow Manager 2 1 0 is transmitted electronically 
5 at step 215 to a Registration, Transfer and Payment ("RTP") module 220. This is a 

stand-alone sub-system which performs the payment functions, and also manages the 
registration and transfer of ownership of the security certificates. Upon completion of 
the payment process, investor reports and other data compilations are disseminated at 
step 225 to the World Wide Web and other outlets. 

10 It should be understood that Workflow Manager 210 represents the present 

invention per se and an embedded processing module 212 which performs the waterfall 
and tax calculations. The specific software preferably used as processing module 212 
is Asset Securitization Analysis Pro ( ft ASAP)" developed by Price Waterhouse/Coopers, 
of Arlington, V A, but it should be understood that other software capable of performing 

1 5 the necessary calculations based on the deal structure, and operable under the control of 

workflow manager 2 1 0 may be used instead. 

The ASAP module 212 also has the capability for so-called "reverse 
engineering". Typically, securitization transactions involve a number of different 
classes of securities (called "tranches") having different effective interest rates, principal 

2 0 repayment schedules, etc. The intended monthly cash flows for the tranches are stated 

in the prospectus for the deal. Reverse engineering involves analyzing the cash flow 
data to create the algorithms for waterfall and tax processing. This function is usually 
performed at the underwriting level but it may readily be performed in accordance with 
a present invention at the trustee level by use of the ASAP module under control of 

2 5 Workflow Manager 210. 
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Workflow Manager 210 provides an interface through which deal set up and 
daily operations may be performed. It also provides task prompting for system users, 
controls data flow from LRPS module 160' and to RTP module 215, manages the 
operations performed by ASAP subsystem 212 and coordinates of the administrative, 
quality control and reporting functions. FIG. 4 illustrates the architecture of a system 
for performing these functions according to the present invention. It should be 
understood that FIG. 4 is a hybrid representing information flow, processing, and 
storage, and is simplified to highlight the functional relationships. 

As illustrated, the functions are preferably implemented on one or more suitably 
programmed general-purpose computers networked together. The system is based on 
a client-server model, with a server side generally denoted 230, and a client side 
generally denoted 232 connected together through a suitable network 234. In the 
embodiment illustrated, there are two separate installations 23 6 A and 23 6B connected 
to network 234 by respective interfaces 23 8 A and 23 8B, but additional installations and 
interfaces may be employed. Having two separate server installations 23 6 A and 23 6B 
provides redundancy and allows geographic distribution of the various functions to 
accommodate the trustee's organizational structure. 

On the client side 232, it is assumed that there are a several Analysts 262a 
through 262n, and Supervisors 264a through 264m, performing their assigned duties on 
separate personal computers connected to network 234. In addition, there is an 
administrator responsible for database maintenance and other similar functions 
performing his or her duties at an additional personal computer 266. Also connected to 
network 234 is a servicer installation 268 corresponding, for example to Loan Servicer 
150 shown in FIG. 3. The system illustrated in FIG. 4 is designed to afford the greatest 
flexibility for distributed processing and redundancy to minimize down time due to 
system problems. In this regard, it may be understood that the various installations on 
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both server side 230 and client side 232 may be located remotely from each other. This 
may be the case, for example, if the trustee has installations in several geographic 
locations. 

Returning now to server side 230, server installation 236a may be comprised of 
5 a large capacity personal computer, mini computer, or main frame installation. This is 
comprised of a suitably programmed command processor 240, a workflow program 242, 
and a Workflow Database 244. As will be understood, the software is stored on a 
suitable storage medium such as a hard drive (not shown). 

Server installation 23 6 A also includes conventional input and output devices 

1 0 such as a keyboard, a monitor, a printer, a mouse, etc., which also have been omitted 

from the drawing in the interest of clarity. Two-way information flow for command and 
data transfer is provided between command processor 240, workflow program 242 and 
Workflow Database 244 by respective signaling paths 240a and 240b. 

Command processor 240 is also connected by signaling paths 240c and 240d to 

15 LRPS unit 160' and RTP 220 previously described in connection with FIG. 3, and by 
signaling path 240c to ASAP subsystem 212. This includes a command processor 246, 
stored ASAP software 248 and ASAP database 250. In will be appreciated that the 
functional units 240 through 250 together correspond to the functions associated with 
workflow management system 210 (see FIG. 3). 

2 0 Also as discussed in connection with FIG. 3, a data signaling path 240 A is 

provided between command processor 240 and World Wide Web server 252 by which 
reports may be distributed to investors and other interested members of the public. 
Other Internet connections may also be provided, e.g., to an FTP site or an E-Mail server 
(not shown). 

2 5 Server installation 23 6B may be similar in construction and architecture to server 

installation 23 6 A. It will be understood, however, that one of the servers will exercise 
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master control and the respective command processors will be programmed 
accordingly. 

The functions performed by Workflow Manager 2 1 0 are preferably implemented 
using standard database management programming. In the embodiment illustrated, the 
5 underlying database management software is Oracle 8, provided by Oracle Corp. of 
Redwood Shores, California. The Oracle software and the implementation of the 
present invention are designed to run on a Unix operating system. However, it should 
be understood that other RDBMS and any other operating system having comparable 
capabilities may be employed instead. 

10 FIGS. 5 A through 5E illustrate the universe of tasks which are performed and 

managed by the present invention. These may be grouped in eight broad categories : ( 1 ) 
deal set-up, (2) monthly data input, (3) waterfall processing (4) waterfall approval, (5) 
waterfall payment (6) report distribution, (7) tax processing and (8) tax approval 

Referring particularly to FIG. 5 A, deal setup involves providing deal structure 

15 information, step 270 and staff/contact information, step 272, in Workflow Database 

244. Monthly data input, mainly aggregated loan level information, is provided by 
LRPS 160'. 

Waterfall processing is a monthly activity, performed by a portion of ASAP 
subsystem denoted 2 1 2a in FIG. 5 A. This comprises a Waterfall Processing module 272 
2 0 and a Bond Analytics module 274. The former performs the actual calculations, while 

the latter provides command processor functions for Waterfall Processing module 272, 
and organizes the waterfall data for use in subsequent processing steps. 

Waterfall Approval, denoted at step 276 in FIG. 5A, involves performance of 
verification or quality control functions which are designed to ensure that the loan level 
2 5 data is accurate and complete, and that the waterfall computations have been properly 

performed. 

00460185.1 
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Upon completion of the waterfall approval process, approval outputs are 
generated at step 278. These provide the necessary data for payment processing by RTP 
system 220 and for generating the investor and other reports (see steps 215, 220 and 225 
in FIG. 3). 

5 After a monthly waterfall computation and payment cycle has been completed, 

the tax processing function may be performed. This is done by a part of the ASAP 
subsystem denoted 212b in FIG. 5 A. This is comprised of a Tax Processing module 
280, which performs the required tax computations, and a Tax Management module 282 
which provides command processor functions for Tax Processing module 280, and 

10 organizes the tax computation data for use in generating the investors' tax reports. 

The final functional categories are tax approval and tax reporting. As in the case 
of waterfall processing, various quality control or verification steps, generally denoted 
at 284, are performed to assure that the tax computations were performed in compliance 
with applicable law and regulations. When this has been completed, the tax reports, 

15 e.g., IRS Schedule forms 1066 and 1099, and schedule Q's are generated at step 286. 

Balance sheets and income statements may also be generated. 

FIG. 5B illustrates the workflow processing order. At the waterfall level 290, 
the monthly investor distributions are computed. The computation labeled February 
(step 292a) is for a February distribution of income earned in January of that year. 

2 0 Similarly, step 292b, labeled March, represents a March distribution of February 

earnings. 

At the Tax-Monthly level 294, tax liability computations are performed, but the 
monthly waterfall processing at level 290 for a particular month must be completed 
before the tax processing for that month can begin. In other words, January tax 
2 5 processing at step 296a, for income earned in January, is performed after the February 
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waterfall processing at step 296a, and February tax processing, step 296b, is performed 
after the March waterfall processing at step 292a. 

The Tax-Quarterly level 298 represents four quarterly tax aggregation/approval 
steps 300a through 300d. As illustrated in FIG. 5B, the February, March, and April 
5 waterfall processing steps 292a through 292c, and the January, February and March tax 
processing steps 296a through 296c, must be completed and before the tax processing 
for the first quarter can be performed. Similarly, the waterfall processing for May, June 
and July, and the tax processing for April, May and June must be completed before the 
second-quarter tax processing at step 300B can be performed. 

1 o Finally, at the Tax Annual level 302, the annual taxes processing is performed 

and approved. As will be understood, this can not be done until the monthly waterfall 
and tax computations and the quarterly tax approvals have been completed. 

Waterfall processing is preferably performed on a monthly basis so that income 
earned in a particular month can be distributed the next month. However, as tax 
1 5 reporting is required only on a quarterly basis, the monthly tax processing is performed 
quarterly, so tax processing generally lags behind Waterfall processing. 

Comparing FIGS. 5A and 5B, it will be understood that FIG. 5A represents a 
single monthly cycle for a single deal. In general, there may be hundreds of active deals, 
each with its own deal structure, and, at a given time, in a different processing stage. 

2 0 Thus, a workflow management system which can reliably track the processing status of 

multiple deals, and prompt the analyst through the steps which need to be done in 
connection with each of the deals on which he or she is working, is virtually essential 
for a successful high - volume operation. 

According to the present invention, to permit the analysts and supervisory staff 
25 to keep track of the status of all active deals, and to perform their tasks in a timely and 

efficient manner, the workflow for the major functions, i.e., waterfall and tax processing, 

00460185 1 
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is organized in a series of steps or queues, each of which is characterized by one or more 
intermediate status milestones. 

FIG.5C illustrates the workflow organization for the waterfall processing 
function. The queues are shown in the normal processing order. 
5 The queues for waterfall processing are LRPS queue 304, Data Prep queue 306, 

Ready for ASAP Processing queue 308, Waterfall Approval queue 312 and Payment 
queue 314. The Run ASAP queue 3 1 0, i.e. , the actual waterfall processing, is performed 
between Ready for ASAP step 308 and Waterfall Approval queue 312. 

Also shown in FIG. 5C are the Tax Processing Function 3 1 6 and Reporting 318. 

1 0 Tax output refers to the ASAP tax processing function previously referred to . Reporting 

represents the distribution of reports in various formats and access locations. These may 
include the World Wide Web, printed reports, Internet bulletin boards and FTP sites, etc. 

As will be understood, the tasks to be performed will vary from queue to queue 
and will depend on the current status milestone. The preferred milestone structure and 

1 5 the tasks associated with each milestone are discussed below. 

Generally, the user performs a task by selecting the task name from an Actions 
List on an Active Deals Screen described in connection with FIG. 1 1 . For some actions, 
e.g., approval, nothing further is required; the workflow management software updates 
the status records for the deal in Workflow Database 244 (see FIG. 4), moves the deal 

2 0 to the next queue and/or milestone, and updates, the listing for the deal on the user's 

Active Deals Screen. For tasks requiring data input, selecting the task brings up a data 
entry screen. For tasks involving review and/or editing of data, the reviewer can bring 
up the appropriate screen to ensure that all data are correct and process the approval or 
the editor can bring up the appropriate screen in order to edit the data. For yet other 

2 5 actions, e.g., Deny, Un- Approve (withdraw an approval) or Restate (i.e. to correct errors 

after a payment has been made), supporting comments are required. In those instances, 
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afterthetaskis selected, a comment entry screen appears. The actions available to the 
user for each queue and milestone, and the associated workflow program actions will 
now be described. 
LRPS Queue 

5 The milestones for the LRPS queue are Not Ready, Data Received, and Denied. 

Not Ready (Default): 

A deal is automatically placed in the LRPS queue and the Not Ready status as 
part of the end of cycle processing under control of command processor 240 when a 
previous payment cycle has been completed. When data for a new monthly cycle is 
1 0 received from servicer 1 50 (see FIG. 3), the status is updated to Data Received, but the 

deal remains in the LRPS queue. This may be done manually, or automatically by the 
workflow management software when the data is received. 
Data Received: 

At this milestone, the available actions are "Approve" and "Deny". The analyst 
1 5 checks the received data, e.g., by reviewing a summary report from the LRPS subsystem 

160 r , and if it is incorrect, incomplete, or otherwise not ready for further processing, the 
Deny action is selected from the Actions List on the Active Deals Screen. After 
supporting comments are entered, the deal is moved to the Data Denied status. 

If the received data is ready for further processing, the Approve action is 
2 0 selected, and the deal moves to the Data Prep queue and the Tape Run status. 

Data Denied: 

At this milestone, the available actions are New Data Received and Approval. 
If new or corrected data is received, the deal remains in the LRPS queue but its status 
returns to "Data Received". If new or corrected data is approved, as previously 
2 5 described, the deals moves to the Data Prep queue and its status is changed to Tape Run. 
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Data Prep Queue 

The status milestones for the Data Prep queue are Not Ready, Tape Run, Loan 
Level Processed and Denied. 
Not Ready: 

At this milestone, the available actions are "Data Entry" and "Approve". If 
information, e.g. concerning loan losses, liquidations, foreclosures, etc. must be entered, 
Data Entry is selected, and an appropriate data entry screen appears. If Approve is 
selected, the deal goes to the Ready for ASAP queue and the Ready status. 
Tape Run: 

At this milestone, the available actions are "Deny" and "Approve". If, e.g., it is 
discovered bad data has been loaded, the system permits correction. To do this, Deny 
is selected, and the deal returns to the LRPS queue and the Data Denied status. If 
approve is selected, workflow command processor 240 runs LRPS Sub-system 160'. 
When that function is completed, the deal is moved to the Loan Level Processed status, 
but remains in the Data Prep queue. 
Loan Level Processed: 

At this milestone, the available actions are "Deny", "Approve", and "Copy". If 
the data is disapproved, e.g., if the beginning balance of a loan does not equal the ending 
balance for the previous month, the Deny action is selected, and the deal remains in the 
Data Prep queue but is placed in the Data Denied status. If the data is approved, the deal 
moves to the Ready For ASAP Processing queue and the Ready status. If the Copy 
action is selected, the LRPS processed data is transferred to the main Workflow 
Database 244 (see Figs. 4 and 5A). 
Denied: 

At this milestone, the available actions are "Deny to LRPS," "Enter Data," "Run 
LRPS," "Copy" "and Approve". If Deny to LRPS is selected (e.g. if an error is 



- 19- 



discovered in the loan-level data), the deal is returned to the LRPS queue and the Denied 
status. To enter losses, liquidations, real estate owned (REO's), for example, Enter Data 
is selected, and an appropriate data entry screen appears. If Run LRPS is selected, the 
LRPS functions are performed and the deal is moved to the Loan Level Processed status 
within the Data Prep queue. The Copy and Approve actions are the same as described 
in connection with the Loan Level Processed milestone above. 
Ready for ASAP Processing Queue 

The associated milestones are Ready and Denied. 

Ready: 

At this milestone, the available actions are denied, "Run ASAP", "Enter Data", 
"Add Special Headers/Footers" and "Add Loan Level Information" . If Deny is selected, 
the deal is returned to the Data Ready Queue and the Data Denied milestone. If Run 
ASAP is selected, command processor 240 initiates the ASAP Waterfall Processing 
function. When this is completed, the deal is moved to the Waterfall Approval queue 
and Ready status. If Enter Data is selected, an appropriate screen appears. When the 
data entry is complete, the deal remains in the same queue and milestone. Similarly, if 
the Add Special Headers/Footers or Add Loan Level Information tasks are selected, 
appropriate input screens appear. Upon completion of the required data input, the deal 
remains in the ready for ASAP Processing queue and Ready status. 
Denied: 

At this milestone, the available actions are "Deny or" Run ASAP". If Deny is 
selected, the deal is returned to the Data Ready queue and the Data Denied status. The 
Run ASAP task results in the same actions described in connection with the Ready 
milestone above. 
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Waterfall Approval Queue 

There is only one milestone for the Waterfall Approval queue, Ready. At this 
milestone, the available actions are "Deny" and "Approve". As previously noted, the 
approval process may involve several verification steps, in which different tests are 
5 applied. If any one of these indicates a problem, the Deny action is selected, and the 
deal moves to the Previous Deny Point with Denied Status. If a particular test is 
successful, the Approve action is selected, and the deal moves to the next approval 
queue, i.e. ready for performance of the next verification test. When the last required 
approval has been given, the deal moves to the Payment queue and Final Approval 
10 status. 

Payment Queue 

The milestones for the Payment queue are Final Approval, Received by Payment 
Systems, and Payment Made. 
Final Approval: 

15 At this milestone, the Waterfall data goes automatically to the RTP subsystem 

for processing. When this has been done, the status is changed to Received by Payment 
Systems. 

Received by Payment Systems; 

There are no specific tasks associated with this milestone. When the payment 
2 0 processing is complete, however, the status of the deal changes to Payment Made. 

Payment Made: 

At this milestone, there are no specific tasks, but the end of cycle processing is 
automatically performed, and the deal is returned to the LRPS queue and the Not Ready 
status. Also, the date for the next distribution is selected. 
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Common Tasks 

In addition to the tasks described above which are associated with specific 
queues and milestones there are tasks or actions which may be performed at all queues 
and milestone levels. These are Comments, Go To Deal History, Cancel, Modify Deal 
5 Contacts, View Rules File, Change Distribution Date, Print Reports and Un- Approve 
(the last two, however, are not available for a deal in the Not Ready status). 

The Comments action is used to record descriptive information at any stage of 
processing, and also to support Deny Un- Approve, or Restate actions. If Comments is 
selected, a comment entry screen described in detail below appears. When the 
1 0 comment has been stored, the comment entry screen closes. The queue and/or status 

changes as necessary for Deny Un-Approve or Restate actions. There is no change in 
queue or status if a comment is recorded for other reasons. 

If the user selects Go To Deal History, an on-screen listing described below 
appears. No change of queue or status results from this action. 
15 Selecting the Cancel action terminates work in progress and returns the user to 

a Main Menu as described below. 

If the Modify Deal Contacts task is selected, the user is presented with a 
staff/contact details screen described below. This may be used to add or modify external 
contacts. (Changes in internal staffing are not permitted) . No change in queue or status 
2 0 is associated with this task. 

The rules file contains information which defines the computation processes for 
a particular deal and the required parameters. Selecting the View Rules File action 
brings up a read only display of this information. 

If an upcoming distribution date needs to be changed for some reason, the 
2 5 Change Distribution Date action is selected. This brings up a data entry screen in which 
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appropriate information is entered. The Print Reports task permits the printing of 
available reports. 

The Un- Approve task is used when approval in a particular queue must be 
withdrawn. For those users authorized to do so, selecting this action brings up a 

5 distribution history screen in which the unapproval is registered, and the comment entry 
screen appears in which the user records a justification for the unapproval. When this 
has been completed, the deal is moved to a new queue and/or status depending on the 
particular deal, function, etc. at which the unapproval took place (usually the first 
waterfall approval stage). 

0 FIG. 5D illustrates the workflow organization for the tax processing function. 

The queues for this function are Ready for ASAP Tax Processing queue 320, Tax 
Analyst Approval queue 325 and Reporting queue 330. The Run ASAP step 335, i.e., 
the actual tax processing, is performed between Ready for ASAP queue 320 and 
Approval step queue. As will be recalled from FIG. 5A, there are monthly, 

L 5 quarterly and annual tax cycles. As indicated by bracket 340 in FIG. 5D, monthly tax 
processing involves the ASAP Tax Processing and Tax Analyst Approval queues. The 
quarterly and annual tax processing functions use data produced by the sequence of 
monthly tax computations, and thus involve only the Tax Analyst Approval and 
Reporting queues, as indicated by brackets 345 and 350. 

20 As in the case of waterfall processing, there are specific tasks and actions 

associated with the tax processing queues and status milestones. These are described 
below. 

Ready for ASAP Processing Queue 

The milestones for the Ready for ASAP Tax Processing queue are Ready and 

2 5 Denied. 
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Ready: 

At this milestone, the actions available are "Enter Data" and "Run ASAP". If 
Enter Data is selected, a tax data entry screen appears. No change in queue and/ or status 
is associated with this action. If Run ASAP is selected, the required data is made 
5 available to the ASAP tax modules and the tax computations are performed. When the 
computations are completed, the deal moves to the Tax Approval queue and Ready 

status. 
Denied: 

At this milestone, the actions available are also "Enter Data" and "Run ASAP". 
L 0 The steps associated with these tasks are the same as described in connection with the 

Ready milestone above. 
Tax Approval Queue 

The milestones for the Tax Approval queue are Ready and Denied. 

Ready: 

15 At this milestone, the actions available are "Deny", "Tax Reports", and 

"Approval-Monthly", "Approval-Quarterly Annual". Selecting Deny moves the deal to 
another queue determined in accordance with the structure of the specific deal. The 
workflow path for this is established during deal set-up, as described below in 
connection with FIG. 7E. The Selection of Tax Reports action brings up a list of tax 

20 reports. 

As in the case of waterfall processing, there may be several levels of approval 
associated with each of the tax processing cycles. As each approval is obtained, the deal 
is moved on to the next approval step. For example, in the case of monthly approval, 
when the last required approval has been given for a particular month, the approval 
2 5 process for the next month begins. Similarly, in the case of quarterly tax approval, when 

one level of approval has been given, the deal moves on to the next required approval 
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level When the last required approval has been given, the deal moves to the Mail 

Reports queue and Ready status. 

Denied: 

At this milestone, the actions available are "Deny", "Tax Reports", Approval- 
5 Monthly and Approval-Quarterly/ Annual Selection of any of these actions results in 
the same sequence of events described in connection with the Ready milestone for the 
Tax Approval queue. 
Reports Queue 

There is only one milestone for the Reports queue, namely, Ready. At this 
1 0 milestone, the available actions are "Mailed" and "Tax Reports". These are applicable 
only to quarterly and annual processing. If the Mail action is selected, the reports are 
printed, the next tax processing cycle is identified, and the deal returns to the Ready for 
Tax Processing queue and Ready status for that period. Selection of the Tax Reports 
action results in the same events described above in connection with the Tax Approval 
15 queue. 

Common Tasks 

In addition to the tasks described, there are several tasks available in all queues 
and milestone statuses. These are Comments, Waterfall Reports, Auto Verification, Go 
To Deal History, Cancel, Modify Deal Contacts and Un-Approve-tax. The events 

2 0 associated with the Comments, Go To Deal History, Modify Deal Contacts and Un- 

Approve actions are the same as described above in connection with waterfall 
processing. Selection of the Waterfall Reports action brings up a list of related waterfall 
reports from which a report may be selected for viewing or printing. Selection of the 
Auto Verification action brings up a list of related automated verification reports 

2 5 described below which are available for the current queue and status milestone, from 

which a report may be selected for viewing or printing. 
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FIGS. 7A through 7H illustrate the Steps Involved In setting up a deal. These 
correspond to steps 270 and 272 shown in FIG. 5 A. 
Staff Information Set-Up 

FIG. 7 A illustrates Staff/Contact Details Screen 600. This is the data entry form 
5 for a Master Contacts Table in Workflow Database 244. Here, information is recorded 

about individuals having responsibility for or other involvement in a particular deal. 
This is accessed by selecting the Staff7Contact Details button 425 on Main Menu 400 
(see FIG.6). 

Screen 600 may be used to select contacts for a particular deal from among 

10 individuals already in a Master Contacts Table, to edit previously existing contact 
information in the Master Contact Table, or to create records for new individuals. For 
names already in the database, the user may select either an ID number from a drop- 
down list for ID field 602 or a last name from a drop-down list for Last Name field 608. 
The data objects on screen 600 are programmed so that when an existing name or ID 

15 number is selected, the remaining fields are automatically populated from the record 
corresponding to the selected name or ID number. 

To edit existing records, the user simply revises the information in the displayed 
fields as necessary, and selects OK push-button 642. This is programmed to display a 
confirmation message, such as, "Are you sure you want to save changes?", and upon 

2 0 confirmation, to update the record, and to return the user to Main Menu 400. It will be 

understood, of course, that the methods associated with OK push button 642 may be 
alternatively programmed so the user has the option to remain in an empty Staff/Contact 
Details Screen 600. 

To add new records to the Master Contacts Table, the user invokes the Add 

2 5 Record function. In the illustrated embodiment, this may be accessed by commencing 

to type information in any of the available fields, but an " Add Record" push button may 
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be provided if desired. New ID numbers may be created sequentially or in any other 
desired manner. For example, employee ID numbers may be used for employees of the 
trustee, and screen 600 may be programmed so that entry of an employee ID number in 
field 602, or the name of an existing employee in field 608, causes the remaining fields 
5 in screen 600 to be populated automatically from the corresponding database record. 

An ID number from a non-employee sequence would be assigned for outside contacts. 

As illustrated in FIG. 7A, the data objects for the City, State, Country, 
Department/Organization and Role fields are programmed as drop-down lists. Existing 
selections may be used when creating a new record, or information may simply be typed 

1 o into the text boxes for the fields. 

After screen form 600 has been completely filled in, the user selects OK button 
642 which functions as previously described. Alternatively, if the user decides not to 
save the newly entered data, a cancel button 640 may be selected. This is programmed 
to display a confirmation such as "Are you sure you do not want to save changes?", and 
1 5 upon confirmation, to discard the changes, and to return the user to Main Menu 400. 

Deal Details Setup 

FIGS. 7B through 7E illustrate a series of Deal Modify data entry screens for 
setting up and/or editing some of the workflow features for a deal. The set up functions 
are accessed by selecting the Deal Details push button 420 on Main Menu 400 (see FIG. 

2 0 6). As illustrated in FIG. 7B, a series of tabs provides access to the different setup 

screens. These include Setup tab 702, Output tab 704, Contacts tab 706, Steps tab 708, 
Quality Control tab 710, Input tab 712, and Header/Footer tab 714. 
Deal Status/Functions 

Screen 700 shown in FIG. 7B corresponds to Setup tab 702. This is used to enter 
2 5 data concerning the status of a deal, the processing functions to be performed, locations 
at which the functions are performed, the frequency of each task and an initial 



00460185 1 



-28- 



distribution date for the function. Screen 700 is programmed to display drop-down list 
boxes 724 and 728 for Deal ID and Deal Status fields, a Deal Description text box 726, 
and an embedded sub-form 723 for entry of information concerning the trustee's 
functions. Deal ID field 724 is linked to a Master Deal Table in Workflow Database 
244. The drop-down list displays the existing deals from which the user may select. 
Records may not be added to the Master Deal Table from screen 700. Changes must be 
made by the database administrator, as described below. 

Deal Description text box 726 is automatically filled in from a record in a Master 
Deal Description Table in Workflow Database 244 corresponding to the entry in field 
724. 

A selection for the Deal Status field 278 is made from a drop-down list which 
may include choices such as New, Active, Dead, etc. The "New" status may 
advantageously by used to designate a deal which is in the setup process. When setup 
has been completed, the deal may be designated as "active". At that time, the deal goes 
"on line", and is managed by the workflow program as described herein. 

Sub-form 723 is comprised of a series of rows, each representing a database 
record for a particular function. The fields (columns) for each record may, for example, 
be Function, 716, Location 718, Frequency 720 and First Date 722. 

The drop-down list for the Function field 716 is linked to a Master Function 
Table in the Workflow Database 244. The entries may, for example, include Waterfall, 
Tax Administration, Paying, etc. 

The drop-down list for the Location Field 718 is linked to a Master Location 
table in the Workflow Database 244, which lists the locations, e.g., processing centers, 
for the trustee's securitization support operations. To accommodate the possibility that 
the trustee performs a single function only at some locations and multiple functions at 
other locations, the database object for field 7 1 8 may be programmed to limit the entries 
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which appear in the drop-down list in accordance with the selection made in field 716, 
For example, if waterfall processing is only done at one location, when " Waterfall" is 
selected for field 716, only that location appears in the field 718 drop-down list. If 
waterfall processing is done at two locations, the drop-down list includes both locations. 
5 The drop-down list for Frequency field 720 is linked to a Master Frequency table 

in Workflow Database 244. This lists the processing periods associated with the various 
deals being managed by the system. The entries may include, for example, "Monthly", 
a specific day of the month (or the previous or next business day), "Quarterly", "N/A" 
(not applicable), the latter for non-periodic activities, etc. Additions to the Master 
1 0 Frequency table may not be made by the user from screen 700, but only by the database 

administrator. 

Some functions may be performed only at specified frequencies; others may 
have no associated frequency. To accommodate this, the data object for field 720 may 
be programmed so the drop-down list displays only permitted values depending on the 
1 5 selection for field 716. 

First Distribution Date field 722 is used to record the initial date or period for 
each function. The data entered here in conjunction with the corresponding data entered 
in field 720 is used to calculate recurring dates for the particular function and is used by 
the workflow prompting functions described below. Field 722 is rendered inaccessible 
2 0 for those functions not requiring an initial date. 

Screen 700 also includes a cancel button 730 and an OK button 732. These 
function as previously described. 

The default structure for sub-form 723 has seven rows, 734, of which the first 
three, such as 734a, contain records corresponding to required functions. Sub-form 723 
2 5 is designed to expand vertically if more than seven functions are required. 
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Report Setup 

FIG. 7C shows data entry screen 750, which appears when Output Tab 704 is 
selected. This is used to enter data concerning reports to be produced. The data object 
for screen 750 is programmed to display a drop-down list box for Deal ID field 782 and 
5 a text box 784, in which a Deal Description is automatically entered, corresponding to 
the Deal ID selected. 

Information concerning the required reports is entered in an embedded sub-form 
786, comprised of a series of rows 788, to display a database record for a particular 
report, and a series columns to display the fields in the record. In the example 
1 0 illustrated, the available fields include Output 752, showing the intended destination for 

the report, Report Type 754, Report Format 756, Release Day 758, Report Title 760. 
There may also be fields for Recipient Name, Company Name, Fax Number, Bulletin 
Board Address and FTP Address (not shown). 

As will be appreciated, depending on the size of the monitor and resolution being 
1 5 employed, the available fields may not all be visible on the monitor at one time. Thus, 
for purposes of illustration, only the first five fields have been shown. A scroll button 
762 on a scroll bar 764 allows display of the remaining six fields. Programming the 
scroll bar may be done in any conventional or desired manner. 

The underlying data object for each field is programmed as a drop-down list box 
2 0 linked to a master table in Workflow Database 244 which displays only the permitted 

entries for that field. 

In the example illustrated, the default structure of sub-form 786 has seven rows 
788, of which the first four, such as 788a, already contain records corresponding to 
required reports. Sub-form 786 is programmed to expand vertically to accommodate 
2 5 additional reports. 
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The drop-down list for the Output field 752 is linked to a Master Output Table 
in Workflow Database 244. The entries may, for example, include Bulletin Board, RTP 
(see FIG. 3), World Wide Web, E-Mail, FTP, etc. 

The drop-down list for Report Type field 754 is linked to a Master Report Table 
5 in Workflow Database 244. The entries may, for example, include Investor's Report, 
Waterfall Report, etc. Fields 752 and 754 are not mutually exclusive. In other words, 
as shown in FIG. 7C, Investors' Reports may be distributed by Bulletin Board, on the 
Internet, and sent to the RTP module (see FIG. 3) for payment processing. Similarly, 
both Investor's Reports and Waterfall Reports may be distributed over the Internet. 

1 0 Thus, one or more Destination/Report Type combinations may be selected. 

Some output destinations may be associated with only one report type, for 
example, only investors' reports would be sent to the RTP module. To accommodate 
this, the drop-down list for field 752 is programmed to display only entries which are 
valid for the selection made in field 754, and vice versa. 

1 5 The drop-down list for Format field 756 is linked to a Master Format Table in 

Workflow Database 244 to display the available report formats. As will be understood, 
the properties of the individual report objects themselves determine the actual report 
format. The preprogrammed formats are designed to accommodate a wide range of user 
access capabilities. For example, available formats may include HTML, ASCII, various 

2 0 commercial spreadsheet format, etc. 

Based on the Output and Report Type selections, the format object may be 
programmed to provide a default format selection. It may also be desired that a given 
report be available in more than one format, and/or that some reports be available only 
in one or more specific formats. The underlying objects for fields 752, 754 and 756 may 

25 be programmed to provide such features. 
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The drop-down list for Release Day field 758 may include selections such as 
"Immediate" , or "Distribution Date" . Selection of the latter displays a text box in which 
a specific date may be entered. The default selection for field 758 is Distribution Date. 
The data object for field 758 is programmed to permit entry of only a single date for a 
5 given report, irrespective of the number times the particular report type appears in sub- 
form 786. 

Title field 760 provides a default report title from a Master Title Table in 
Workflow Database 244 depending on the report type selected in field 754. However, 
the underlying data object is programmed to permit the default to overridden. 
1 o The remaining fields, pertain to information about the intended recipient of the 

report. The data objects for these fields are programmed to display drop-down lists 
linked to the Master Contacts Table. Preferably, the objects for Recipient Name, 
Company, and Fax Number are programmed to permit selection only from the 
associated list box, while the objects for the Bulleting Board, FTP Address and Others 
1 5 fields may accommodate manual data entry. 

There are also available Cancel and OK push buttons 778 and 780. These 
function as previously described. 
External Contact Setup 

FIG. 7D shows data input form screen 800, which appears when Contacts tab 
20 706 is selected. This screen is for selection of external contacts for a particular deal. 

New contact entries are not made from this screen; this must be done from screen 600 
(see FIG. 7 A), accessed by selecting the Add New Contact push button 820, or by push 
button 425 on Main Menu 400 (see FIG. 6). 

Screen 800 includes a drop-down box 802 which displays a list of deal 
2 5 identification numbers and a text box 804 in which a Deal Description is automatically 

entered, depending on the deal ID selected in drop-down list box 802. 
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The selected contacts are listed in an embedded sub-form 830, comprised of a 
series of rows 832, each displaying database record for a particular individual or 
company, and five columns 8 1 0 through 818, which display the fields in the respective 
records. 

In the illustrated example, the available fields are Name 810, Company 812, 
Role 814, Phone 816 and Address 818. The data object for each row is programmed as 
a drop-down list box linked to a Master Contacts table but is programmed to display 
only external contacts. The list is in alphabetical order, sorted by last name or by a 
company name, depending on whether Sort By Name radio button 806 or Sort By 
Company radio button 808 is selected. The default entry is blank. Advantageously, the 
drop-down list object may be programmed for smart look-up, i.e., the list scrolls 
automatically as a sequence of letters are typed in the text box. Upon selection of a 
contact, all the columns (fields) for that record are automatically populated. 

In the example shown, the default structure for sub-form 830 comprises eight 
rows 832, of which the first two, 832a and 832b, contain records corresponding to 
selected contacts. It should be understood, however, that the number of contacts 
associated with a particular deal may vary, and sub-form 830 is programmed to expand 
vertically as necessary. 

Screen 800 also includes Cancel and OK push buttons 822 and 824. These 
function as previously described. 
Queue & Responsibility Setup 

FIG. 7E shows data entry form screen 850, which appears when Steps tab 708 
is selected. This screen is for set up of the queues for each function as described in 
connection with Figs. 5C and 5D, and other information concerning those functions, 
such as the order of the processing steps and the responsible internal staff member. 
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Screen 850 includes a drop-down list box 882 which accesses a list of deal 
identification numbers and a text box 884 in which a Deal Description is automatically 
entered, corresponding to the selected Deal ID. 

Screen 850 also includes an embedded sub-form 852, comprised of a series of 
5 rows 856 which display the database records for the selected queues, and six columns 

856 through 862 which display the fields (described below) in the respective records. 

Sub-form 852 includes a drop-down list box 854 linked to the Master Function 
table in Workflow Database 244 from which the available processing functions are 
selected. As discussed in connection with FIG. 5C, these include Waterfall-Monthly, 
10 Tax-Monthly, Tax-Quarterly, and Tax- Annual Using sub-form 852, the workflow 
details for each function are specified separately. The functions are selected (in drop- 
down list 854) one at a time, and the desired information is entered in each of fields 856 
through 862. After a function has been set up, the information is stored using OK push 
button 870, Screen 850 is then re-accessed, and the process repeated as many times as 
15 necessary to set up all the required functions. 

In the example illustrated in FIG, 7E, the default structure for sub-form 852 has 
ten rows 863, of which the first eight, such as 863a, contain records corresponding to 
selected queues for the Waterfall-Monthly function selected in list box 854. Since the 
number of queues required may vary depending on the function, sub-form 852 is 
2 0 programmed to expand vertically as necessary. 

The five fields available in sub-form 852 are a Deny field 856, a Queue Type 
field 858, aName field 860, a Role field 861 and a Date Due field 862. Deny field 852 
is programmed as a series of check boxes. Queue Type field 858 is programmed as a 
drop-down list box linked to a Master Queue Table in Workflow Database 244. 
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As will be understood from FIGS. 5C and 5D previously described, the available 
queue types are different for each function. Field 858 is programmed to present only 
those queues applicable to the function selected in field 854. 

The drop-down list presents the available queues in the default processing order. 
5 However, one of the programming features of field 858 is that the sequence may be 
edited using the Insert push button 864, which adds a blank line preceding a selected 
line and the Delete button 866, which deletes a selected line (a confirmation query may 
be presented, if desired, which must be responded to before the actual deletion takes 
place). 

! o Another programming feature of field 858 is that more than one entry may be 

selected from the drop-down list, e.g., by using the CTRL and SHIFT KEYS on a 
standard keyboard in conjunction with a mouse or other pointing device. In addition, 
some queues may be repeated, while others may be used only once for each processing 
function. For example, the Release to Output and Run ASAP queues are performed 

1 5 only once per processing cycle, but the Approval queue may be used as many times as 
necessary for the verifications which will be performed. 

Name field 860 is used to identify the individual responsible for the particular 
queue. The drop-down list for this field is linked to the Master Contacts Table. Only 
internal staff names are listed, and selections are limited to those names on the list. 

2 o Among the other programming features of the drop-down list for field 860 are 

alphabetical ordering by last name, smart look up, and vertical scrolling. Upon selection 
of a responsible individual from the list, the Role field 861 is automatically filled in 
from data in the Master Contacts Table. 

A name must be selected for each queue, except that name selection is not 
2 5 permitted for the Run ASAP and Release To Output queues. Otherwise, names can be 

used and repeated as needed. 
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Due Date field 862 represents the date of the month on which the particular 
queue is expected to be completed. In the illustrated example, field 862 is programmed 
as a text box which accepts numeric entries from 1 through 28. As will be understood, 
only one date may be selected for each line 863 in sub-form 852. 

Referring back to Deny field 856, there is a check box such as 886(a) associated 
with each existing line in sub-form 852. These are programmed as flag fields, and the 
presence or absence of a check in a particular box defines the data flow path in the event 
of a data or processing error which results in a "Deny" action. For a denial in a 
particular queue, the task is returned to the nearest checked queue above in the 
processing order, except that if the denial takes place in a checked queue, the task is 
returned to the immediately previous queue. The name of a responsible individual must 
be entered in Name field 860 for any Deny field which is checked. 
Verification Setup 

FIG. 7F shows a data entry screen 900 which appears when Verification tab 7 1 0 
is selected. This is used to specify pre-defined automated verification (quality control) 
procedures. The manner in which these procedures are defined is described in detail 
below in connection with FIGS. 15 through 17. 

Screen 900 is linked to the Master Deals Table, and is programmed to display 
a drop-down list of existing Deal ID numbers from which the entry for field 904 is 
selected. A Deal Description text box 906 is automatically filled in with a deal 
description corresponding to the selected Deal ID. Also displayed is an embedded sub- 
form 902, comprised of a series of rows 908, which display the database records for the 
selected verification procedures, and three columns 9 1 2 through 9 1 6 as described which 
display the fields described below in the respective records. 

In the illustrated example, the available fields (columns) for sub-form 902 are 
Function 912, Queue 914 and Procedure Name 916. The data object for field 916 is 
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programmed as a drop-down list box linked to a Master verifications table with the 
drop-down order corresponding to the order in which the verification are performed. As 
many selections from the list may be made as needed (using, e.g., the SHIFT and CTRL 
Keys and the pointing device, but selections may not be repeated. Selected entries (in 
5 the drop-down order) then appear in column 9 1 6, and the corresponding data for fields 

912 and 914 are automatically entered. The update is canceled or saved using push 
buttons 918 or 920 respectively. 

In the example shown, the default structure for sub-form 902 is comprised of 
eleven rows 908 of which the first three, such as row 908a, already contain records 
10 corresponding to selected procedures. Sub-form 902 is programmed to expand 

vertically as necessary. 
Input Setup 

FIG. 7G shows a data entry screen 922 which appears when Input tab 712 is 
selected on one of the deal modify screens shown in FIGS 7A through 7F. This is used 
15 to define summary (input) fields which implement the interface between LRPS 
subsystem 160' and ASAP subsystem 212 (see FIG. 3) by mapping the LRPS data 
structure to the ASAP data structure. This mapping will generally vary from deal to 
deal, so the mapping process is a necessary part of the deal setup. 

Screen 922 is programmed to display two side-by-side windows, an ASAP 
20 window 924 and an LRPS window 926. ASAP window 924 is comprised of two 

columns, a Field Name column 928 and a Label column 930. LRPS window 926 is 
similarly comprised of a Field Name column 932 and a Label column 934. When screen 
922 is opened, each column includes several aligned blank rows such as 936a, 936b, etc. 
Data to be entered in the rows of columns 928 and 930 are selected from smart 
2 5 search drop-down lists controlled by respective search buttons 937 and 938. The 

selections available in the drop-down lists correspond to the database field names for the 
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ASAP and LRPS subsystems respectively. Columns 930 and 934 may be used for 
manual entry of descriptive names corresponding to selected database field names. 

Screen 922 may be used in two ways. The empty fields of columns 928 and 932 
may be populated on a line by line basis, in which case the analyst will use the smart 
search buttons 936 and 938 to select the field names to be mapped. 

Alternatively, the user may create a template based on some earlier deal. To do 
this, the user clicks on the Copy From pushbutton 940, which brings up a list of existing 
deals from which the user may select. Upon making a selection, the fields in columns 
928, 930, 932 and 934 are automatically populated with the field mapping from the 
selected deal. This, in turn, may be edited to define the mapping for the new deal being 
set up, by clicking on the field to be edited and selecting a new item from the list. 

The LRPS fields which are to be used for a particular deal are specified by use 
of check boxes 940 adjacent each row of column 932. Particularly, if a template is 
invoked (by use of the Copy From button) there may be LRPS fields not needed for a 
particular deal. The selected check boxes indentify the fields which are required. 

FIG. 7G shows an exemplary mapping. (A conventional scroll button 942 may 
be programmed to appear when the number of rows exceeds the default capacity of the 
screen.) It should be understood, however, that FIG. 7G is purely illustrative, as the 
mapping may vary from deal to deal, and not all available ASAP or LRPS fields may 
be needed. Also, information needed for one or more ASAP fields may not be available 
in the LRPS database. In that event, data for the particular parameter may have to be 
entered manually when needed. To accommodate this, the LRPS Field Name entry in 
a particular row is left blank. 
Header/Footer Setup 

FIG. 7H illustrates a data entry screen 970 which appears when Input tab 7 1 4 is 
selected on one of the Deal Modify screens shown in FIGS 7A through 7F. This is used 
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to define standard headers and footers which will appear on the monthly reports for a 
particular deal. 

Screen 970 is comprised of a drop-down list box 972 from which the name of 
an active deal may be selected, and an embedded sub-form 974. Sub-form 974 is 

5 comprised of a Description field (column) 976 and a Label field (column) 978. 
Description field 976 is programmed as a series of manual entry text boxes representing 
the actual text of a header or footer. Label field 978 is preferably programmed to 
display a drop-down list of header and footer locations, e.g., "Cover page footer", "Text 
page header" or the like. 

10 Like screen 922 (FIG. 7G) screen 970 may be used in two ways. The empty 

fields in columns 976 and 978 may be populated on a line by line basis, in which case 
the user will select labels from the drop-down list box, and will manually enter the text 
for the particular header or footer in the succession of rows 980a, 980b, etc. 
Alternatively, the user may create a template based on some earlier deal by clicking on 

1 5 the Copy From pushbutton 982, which brings up a list of existing deals from which a 

selection may be made. Upon making a selection, the cells in sub-form 970 are 
automatically populated with the header/footer information from the selected deal. 
These, in turn, may be edited to define the headers and footers for the new deal being 
set up. 

2 0 Index Rate Data Entry 

FIG 8 illustrates a data entry screen 1000 which is used to enter index rate 
information. This screen is accessed when pushbutton 415 on Main Menu 400 is 
selected (see FIG.6). Index rate information is used for those deals in which the bonds 
have variable interest rates keyed to a published index. For example, a particular bond, 

2 5 or one of the classes of bonds in a deal, may have an interest rate expressed as "one 

month LIBOR rate on a particular date plus 20 basis points." ("LIBOR" is the London 
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InterBank Offered Rate, the base interest rate paid between banks trading Eurodollars. 
It is quoted for one, three, six and twelve month periods, and changes daily. A "basis 
point" is 0.01%.) 

The parameters and variables for rate computations on all active deals are stored 
5 in a Master Rules Table in ASAP database 250 (see FIG. 4). The analyst uses screen 
1000 to record the daily fluctuations of the various indices applicable to the deals for 
which he or she is responsible. 

Screen 1000 includes an Name field 1005, a Description field 1010, a Source 
field 1015, and an embedded sub-form 1 020. The latter is comprised of a series of rows 
10 1 025 and field columns 1030 and 1 03 5 in which dates and corresponding rate values for 

the Index selected in field 1005 may be entered. Sub-form 1020 is initially comprised 
of nine rows but expands vertically as necessary. 

When a deal is being set up, data is entered in fields 1005, 1010, 1015 and 1030. 
A required index rate is selected from the drop-down list linked to a Master Index Rate 
1 5 Table in Workflow Database 244, and entered in field 1005. The entries include various 
customarily used indices such as 1 month LIBOR, 3 month LIBOR, etc. Description 
field 1010 is also linked to the Master Index Rate Table, and is automatically filled in 
with information corresponding to the selected Index Rate. 

Source field 1015 is also a drop-down list which is linked to the Master Index 
2 0 Rate table. The drop-down list for this field includes the sources such as the Wall Street 
Journal, etc. in which the various indices are published. Field 1 030 is used to enter the 
applicable dates (e.g., the dates required for interest calculations on the succession of 
monthly distribution dates) for the new deal. 

As part of the analysts' daily activities, screen 1000 is updated by entering in 
25 field 1035, the value published in the applicable source for those indices having that 

day's date in column 1030. Cancel and OK buttons (not shown) are also be provided and 
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function as previously described. Screen 1 000 may be used repetitively if necessary to 
specify more than one index rate both during setup and on a daily basis. 
Global Staffing Changes 

FIG. 9 illustrates Global Staff/Contacts Screen 1050 which is used to make 
5 changes in assigned staff and contacts for more than one deal at a time. Screen 1 050 is 

accessed by selecting push button 455 in main menu 400 (see FIG. 6), 

Screen 1050 is programmed as a combined query creation and report form. 
Upper portion 1052 of screen 1050 contains a Staff/Contact field 1055, a Queue Type 
field 1060 and a Replacement field 1065. Together, these specify the parameters for an 
1 0 "assigned deal" query. 

On the lower portion of screen 1500, a sub-form 1070 displays a report based 
on the data returned by the query. 

The drop-down lists for fields 1055 and 1065 are linked to the Master Contact 
Table. Programming features may include alphabetical listing by last name, and smart 
15 look-up as previously described. Fields 1055 and 1065 are blank by default. Since 

screen 1050 represents replacement for a single individual, only one name is entered in 
field 1 055, Replacements must have the same role (as indicated in the Master Contacts 
Table) as the person being replaced. 

The drop-down list for Queue Types field 1060 is linked to the Master Queue 
2 0 Table. The staff assignment changes are made on a queue by queue basis so only a 
single queue type may be selected at a time. The default condition for Queue Type 
field 1060 is blank. If it is left blank, it is assumed that all queues for which the 
outgoing individual had responsibility are to be updated. Sub-form 1070 then lists all 
of the Deal ID numbers, the Deal Names and the Queue Types for which the outgoing 
2 5 individual was responsible . 
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When the user has completed the entries for sub-form 1070, the Replace push 
button 1080 is pushed. This saves the changes and clears screen 1050 in preparation for 
further use. To save the changes and return to main menu 400, OK push button 1085 
is pushed. To return to the main menu without saving the changes, the user pushes 
5 cancel button 1080. In both instances, confirmation messages as previously described 
are displayed before the requested actions are executed. 
Privilege Level Setup 

FIG. 10 illustrates Access Screen 1 100 which is used to assign access levels to 
various users according to their responsibilities. This screen is accessed by selecting the 

1 o Security & Access push button 450 on main menu 400 (see FIG. 6). 

Screen 1100 displays a Role field 1105 and a sub-form 1110 which displays 
functions and activities for which different privilege levels may be assigned and check 
boxes by which the desired privilege levels may be selected. 

The drop-down list for Role field 1 1 05 displays an alphabetical listing of internal 
15 staff roles required for performance of the trustee's functions. New internal staff 

functions may also be entered for field 1 1 05 . When a selection has been made in field 
1105, sub-form 1110 displays a list of the functions corresponding to the push buttons 
on main menu 400 in column 1 125 and the activities associated with each function for 
which different levels of access may be assigned in column 1 130. 

2 o Privilege level selection is made using two columns of check boxes 1 1 35 and 

1 140, labeled Read and Write, respectively. By default, the check boxes are empty; 
placing a check establishes access to a particular function and activity for inquiry 
purposes, i.e., for the role selected in text box 1105. The Read privilege (which includes 
the ability to print) represents access to a particular function or activity only for inquiry 
2 5 purposes, i.e., only to review the data. The write privilege represents the ability to edit, 

as well as view data. 
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Screen 1 100 also includes a cancel push button 1 1 15 and an OK push button 
1 120, both of which function as previously described. 
Active Deal Processing 
The Active Deals Screen 
5 FIG. 1 1 illustrates Active Deals Screen 1 500 . This may be accessed, for example 

from a menu bar (not shown), or in any other desired manner, and is basically the daily 
starting point for the tasks performed by the trustee' s employees. Screen 1 500 provides 
a workflow status summary (essentially a "to do" list) of the deals for which user is 
responsible. The user can also initiate various tasks by selecting from a pop-up Action 
1 o List on the Active Deals Screen. 

Screen 1 500 is programmed as a combined query creation and report form. In 
the illustrated example of FIG. 11, upper portion 1502 contains a User (name) field 
1505, aDeal Name (ID) field 1507, a Function field 1510 andaQueue Type field 1515, 
and radio buttons 1520a and 1520b which select between Current Items, i.e., those 
1 5 queues which are in "ready for action" status, or All Items, i.e., all deals that are related 
to that user, regardless of status. Together, these specify the data for an "active deal" 
query. On the lower portion of screen 1500, a sub-form 1504 displays a report based 
on the data returned by the query. 

The drop-down list for User field 1505 is linked to the Master Staff/Contact 
20 Table. Programed features for this field include limiting the drop-down list to staff 

names only, alphabetizing by last name, smart look-up and limitation to selection of 
only one name at a time. The default entry in text box 1505 is the name of the logon 
user. 

Selection for Deal Name field 1 507 is made from a smart look-up drop-down list 
2 5 linked to the Master Deals table. All active deals are listed. Selection for Function field 
1 5 1 0 is made from a smart look-up drop-down list linked to the Master Functions Table. 
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Choices may include Waterfall-Monthly, Tax-Monthly, Tax-Quarterly, Tax-Annual. 
The default entry is blank; the user may select only one function at a time. 

A smart look-up drop-down list for Queue field 1515 is linked to the Master 
Queue Types Table. Only queue types applicable to the entry in Function field 1 5 1 0 are 
shown, with the entries listed in processing order. The default entry is blank; only one 
queue type may be selected. 

Any or all of the fields in query form 1502 may be left blank. In that case, the 
state of radio buttons 1 520 will solely determine the data returned. If radio button 1 520a 
(the default value) is selected, the query will return a list of all ready queues for all 
active deals. If radio button 1 520b is selected, the query will return a list of all queues 
for all active deals. 

Ifa selection has been made in one or more of fields 1505, 1507, 1510and 1515, 
the query will return data accordingly. For example, if radio button 1520a is selected, 
and the User field is left blank but entries are made in the Function and Query fields, the 
query will return a list of all deals which are in the specified queue for the selected 
function, and for which the queue is ready for processing. If there are entries in the User 
field and the Function field, but not in the Queue field, the query will return a listing of 
all of the user's deals for the specified function, for all queues ready for processing. 

Report sub-form 1 504 displays a row for each deal record which meets the query 
selection criteria, and a succession of columns displaying the fields in each record. In 
the example illustrated, a first column 1525 contains the entry "R" if the deal is in 
restatement, but is blank otherwise. 

Again, by way of example, eight columns 1530a through 1530h display fields 
such as Deal ID 1530a, Deal Name 1530b, Period (distribution date) 1530c, Function 
1530d, Queue 1530e, Status 1530f, Date In Queue 1530g and User 1530h. It should 
be understood, however, that some of these fields may be omitted and others added or 
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substituted. The named fields have been described in detail previously, and need not be 
repeated. Similarly, the status codes for the various queues were discussed in 
connection with FIGS. 5C and 5D. 

The Date In Queue column 1530h represents the date of the last status change. 
5 Time may also be presented if desired. The User field 1530h represents the individual 

responsible for the deal in its current status. 
The Actions List 

When the report in sub-form 1525 first appears, none of the rows is highlighted. 
When the user selects one of the rows, e.g., by right-clicking, a pop-up Actions List 
10 1535 for that particular deal appears. This list is linked to a Master Action Table in 

Workflow Database 244 and is programmed to display only actions which may be taken 
for the selected queue and status, as described in connection with FIGS. 5C and D. In 
FIG. 1 1, the actions listed in pop-up menu 1535 correspond to a deal in the Waterfall 
Processing function, in the "Ready For ASAP Waterfall Processing" queue, and in the 

15 "Ready" status. 

All of the actions permitted or required for the function, queue and status of the 
deal highlighted on sub-form 1504 may be accomplished or initiated by selecting an 
item from the Actions List. For the example illustrated in FIG. 11, these include 
disapproving or un-approving a queue, running one of the ASAP computations, 

20 inputting data, viewing deal structure information, viewing deal history, viewing or 

generating reports and resetting the workflow, i.e. going back to the beginning of the 
workflow cycle, typically the LRPS queue. It will be understood that "Approval" is not 
an available option as the status of the current queue, "Ready for ASAP Processing" is 
"ready", i.e., already approved. 
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Reports 

Selecting Deal Reports line 1535c inActions List 1535 brings up a window 1540 
illustrated by way of example in FIG. 12A. Window 1540 accesses the list of reports 
for the highlighted deal selected during deal set-up as described in connection with FIG. 
5 7C. These may include, for example, Investor Report, Loan Level Detail, Waterfall, etc. 

The available selections are limited, however, to those reports applicable to the function 
selected in field 1515 (see FIG. 1 1) and to the current queue for the selected deal. 

Selecting one of the reports from the list, e.g., by highlighting and clicking on 
the entry, generates the selected report. If the report already exists, it is brought up for 
1 0 viewing and printing. 

Approval and Disapproval 

The Deny, Un-Approve and Approve functions are initiated by clicking the 
respective lines on the Action List 1535, when these actions are available for the 
selected deal, function and queue. (See, e.g. lines 1535b, 1535fand 1 53 5e, respectively 

15 in FIG. 11). 

Selecting Approve updates the status record for the deal and returns the user to 
the active deals screen. Selecting Deny or Un-Approve brings up a Comments History 
Screen, an example of which is illustrated 1550 in FIG. 12B. The Comments History 
Screen 1550, displays the Deal ID in text box 1555a, the Deal Description in text box 

2 0 1555b, the Period Ending date in text box 1555c and the Function in text box 1555d. 

The data corresponds to the highlighted entry in Active Deals Screen 1500 (see FIG. 
11). 

A listing of previous comments, with the most recent one first, appears in an 
embedded sub-form 1 560. Each row 1 565 represents the record for one comments. The 
2 5 fields for each record are displayed in columns 1 570. The first of these, column 1 570a, 
displays the letter "R" if the deal is being restated, and is blank otherwise. Date column 
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1570b, Function column 1570c Queue column 1570d, Status column 1570e, Name 
column 1570f, Comment Type column 1570g and Comment Details column 1570h 
display information concerning the deal at the time the comment was made. 

New comments are not added from screen 1550. Instead, clicking on an Add 
push button 1575 brings up a Comment Entry Screen illustrated in FIG. 12C and 
described below. Comments List Screen 1 550 also displays a Cancel push button 1580 
and an OK push button 1585. Pressing Cancel push button 1580 displays a confirmation 
dialog box including a message text and "yes" and "no" buttons (not shown). If entry 
to Comments History Screen 1550 was from a Deny action, the message text is 
preferably "You must select a comment or deny will not take effect. Do you wish to 
cancel deny?" If the user pushes the "yes" button, Active Deals Screen 1 500 reappears. 

If the entry to Comments History Screen was from an un-approval action, the 
message text is preferably "You must select a comment or unapprove will not take 
effect. Do wish to cancel unapprove?" If the "yes" push button is selected, the user is 
returned to the Distribution History screen described below in connection with FIG. 
12D. 

If entry to the Comments List screen was from a Restatement action, the 
message text is preferably "You must select a comment or reinstatement will not take 
effect. Do you wish to cancel reinstatement?" If the "yes" push button is selected, the 
user is returned to the Distribution History screen. 

If none of the foregoing conditions apply, the message text is preferably "Are 
you sure you do not want to save changes?" If the "yes" push button is selected, the user 
is returned to Main Menu 400. 

In all of the foregoing situations, if the "no" button is pushed, the cancel action 
is terminated, and Comment Entry Screen appears. 
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The OK button 1585 displays a confirmation screen (not shown) including "yes" 
and "no" push buttons and a message which preferably states "Are you sure you want 
to save comments?" Selecting the "yes" push button confirms the action take, saves any 
associated comment, and returns the user to the originating screen. 
Comment Entry 

Referring to FIG. 1 2C, Comment Entry Screen 1 590 displays a Deal ID text box 
1595a, a Deal Description text box 1595b, a Period Ending text box 1595c, a Function 
text box 1 595d, a Queue text box 1 595e, a Status text box 1 595f and a Name text box 
1595g. The information displayed is copied from the screen in which the Comment 
Entry screen 1590 was selected. Queue text box 1595e, and Status text box 1595f 
respectively display the current queue and status of the deal. Text box 1595g lists the 
name of the person making the comment; this is taken from the Logon ID. 

Screen 1590 also includes a drop-down list box 1600 linked to a Master 
Comment Table in Workflow Database 244 which displays a list of possible comment 
types. All of the types of issues which might arise are listed, preferably in the order in 
which the issues are likely to arise. In the example illustrated in FIG. 12C, the "Model 
Incorrect" comment type has been selected. 

When a comment type has been selected, an Additional Comments text box 1 605 
becomes accessible. Here, the user may enter free-form text expanding on the comment 
type selected from list 1600. 

A cancel button 1610 returns the user to Comments List Screen 1550 (see FIG. 
1 2B) without saving changes. Pressing cancel button 1610 brings up a confirmation box 
with associated "yes" and "no" push buttons and a message text box (not shown). If the 
entry to screen 1550 was from a deny action, an un-approve action or a restatement 
action, a comment is required. If no comment type has been selected for some reason, 
the user is appropriately prompted, e.g., "You must select reason for denial". 
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Screen 1590 also displays an OK push button 1615 to save the information 
entered and to return the user to Comments History Screen 1 550. Upon pressing push 
button 1615, a confirmation box and "yes" and "no" push buttons (not shown) appear. 
If the entry to 1550 was from an action for which a comment is required, and no 
5 comment has been recorded, a confirmation box presents a message prompting the user 
to make a comment. Otherwise, the confirmation message preferably reads "Are you 
sure you want to save comment". An affirmative answer saves the comment, and 
returns the user to the Active Deals Screen. 
Deal History 

1 0 Selecting Go to Deal History line on Actions List 1535 brings up a Deal History 

Screen, an example of which is shown at 1620 in FIG. 12D. Screen 1620 is 
programmed as a combined query and report form. An upper query portion 1622 
displays a drop-down list box for aDeal ID field 1625, a drop-down list box for Period 
Endingfield 1630 and a drop-down list box for Function field 1635. A Deal Description 

15 corresponding to the Deal ID entered in 1625 is automatically entered in a text box 
1 640. The list box for Period Ending field 1 630 is linked to a Master Deal Distribution 
Table and presents a list of the current and all previous distributions sorted with the 
most recent distribution first. The drop-down list for Function field 1635 is linked to 
the Master Function Table and presents a list of available functions in the normal 

2 0 processing order. 

The information returned in accordance with the selections made in fields 1 625, 
1630 and 1635 appear in an embedded report sub-form 1645. This includes rows 1650 
which display the records for each event matching the selection criteria for the query, 
and columns 1655a through 1655e which display the Queue, Status, Action, Date/Time 

2 5 Completed and Name fields for eachrecord. The records in line 1 650 are listed in queue 

order 

00460185 1 



-50- 



The report appearing in sub-form 1645 is for information purposes only; no 
action can be taken from screen 1620 other than to return to main menu 400 by pressing 
pushbutton 1560. 

FIGS. 1 3 A through 1 3D illustrate examples of data entry screens which may be 
5 used to supply data required for the waterfall processing functions. These screens may 
be accessed by selecting the corresponding action from Actions List 1 535 on the Active 
Deals Screen 1500(see FIG. 11). 

FIG. 1 3 A shows Monthly Collateral Processing Screen 1 700 which may be used 
for entry of information not available from LRPS subsystem 160' (see FIGS. 3 and 4), 
L0 and also to review information from the LRPS subsystem 160'. Screen 1700 displays 

smark search drop down lists for Deal ID field lists 1705 and a Date field 1710 from 
which the user may select the deal ID and a distribution date.. The entry for field 1705 
is selected from a smart search drop-down-list which displays the active deals. A text 
box 1715 displays a deal description based on the selected deal ID in field 1705. The 
15 entry for field 1705 is selected from a smart search drop-down-list which displays the 
list of upcoming distribution dates for the selected deal. 

Another text box 1720 is used to enter data identifying groupings within the 
underlying collateral for the selected deal. Such groupings might represent, for 
example, discount loans. A "Next" pushbutton 1725 and a "Previous" pushbutton 1730 
2 0 may be used to step through the list of group numbers. 

Monthly Collateral Processing Screen 1700 also displays a Label column 1740 
and a Value column 1745. The labels in column 1740 are the ones set up on input 
screen 922 (see FIG. 7G). In the series of text boxes forming Value column 1745, the 
user can insert values corresponding to the labels. 
2 5 After the required data has been entered in Value column 1 745, the user may 

select Save push button 1750. This saves the data and clears screen 1700, which then 
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remains available for further use. To exit Monthly Collateral Processing Screen 1700, 
the user may select Exit push button 1 752, and is returned to Active Deals Screen 1 500. 

FIG. 13B illustrates an exemplary Loan Reporting Screen 1775 which may be 
used to enter loan level information not available from LRPS 160'. FIG. 1 3C 

5 illustrates a Report Deal Setup screen 1900 which may be used if special headers or 

footers are required for report currently being prepared. The data objects for screen 
1900 are the same as for Common Report Deal Setup Screen 970 described in 
connection with FIG. 7H, and further description will be omitted in the interest of 
brevity. It should be noted, however, that screen 1900 is used to enter data applicable 
10 only to the current report, there is also displayed a Select PayDate Screen 1910, 

selections for which are made from a smart search drop-down list 1905, containing the 
specific distribution dates for the deal. 

FIG. 13D illustrates a data entry screen 1950 which may be used to change a 
distribution date if it was not calculated correctly by the system. This might happen, for 
15 example, if the date selected is a "floating" day, i.e. where the payment date for a 
particular deal is not the same each month. Screen 1950 may be accessed from Actions 
List 1535 on Active Deals Screen 1500. 

Screen 1950 displays a Deal ID text box 1955, a Deal Name text box 1960, a 
Current Distribution Date text box 1965 and a Corrected Distribution Date text box 
2 0 1970, an OK push button 1 975 and a Cancel push button 1 980. The data displayed in 

text boxes 1955, 1960 and 1965 is copied from the Active Deals Screen. The corrected 
distribution date defaults to the current distribution date; this is the only field in screen 
1950 for which manual data entry is permitted. 

If the user decides not to change the distribution date, Cancel push button 1980 
2 5 may be selected. This display a confirmation message such as "Are you sure you do not 

want to save changes", and upon acknowledgment, returns the user to Active Deals 
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Screen 1500. To replace the current distribution date with the corrected date, the user 
presses OK push button 1975. This displays a confirmation message such as "Are you 
sure you want to save changes" and upon an acknowledgment, the data is saved and the 
user is returned to Main Menu 400 (see FIG. 6). 
5 FIG. 14 illustrates Tax Reports Screen 2000 from which the user selects tax 

reports to be generated. This action is selected from Actions List 1 53 5 on Active Deals 
Screen 1500 (FIG 11). (As will be understood, Actions List 1535 will display this 
activity only when the selected deal is in a tax processing queue and status milestone for 
which it is appropriate.) 
! o Available reports are listed in lines 2005a through 2005e on screen 2000. In the 

example shown, these include IRS Schedule Q and Forms 1066 and 1099, a deal 
Balance Sheet and a Deal Income statement. It will be understood that the data objects 
for these forms are set up and formatted using the standard form creation and formatting 
functions of the RDBMS. 
15 Verification 

As it will be appreciated, verification of the accuracy and completeness of the 
loan level and other deal specific data and the results of the numerous computations are 
essential components of the trustees' activities. With a large number of active deals in 
progress at one time, the need to handle large bodies of data which change from month 
20 to month (or in some cases, even more frequently) the complexity of the deal structure 

and the structural variations from deal to deal, it may be understood that one or two 
simple cross-checks will not be enough to establish the required level of confidence for 
the trustee's activities. The present invention provides a practical and effective way for 
the analysts - usually the one most familiar with a particular deal ~ to develop and 
2 5 apply verifications uniquely suited for that deal. 
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Broadly stated, the verification process involves the development of a set of 
verifications, assignment and customizing of particular verifications to each deal and the 
application of particular verifications in accordance with the requirements of a particular 
queue and status milestone. According to the present invention, templates are created 
5 representing a standard reporting format, and any necessary special formatting 

requirements along with a series of data input forms in which the end user can select the 
specific parameters and variables which may be required, or to define new deal specific 
parameters if necessary, and to construct the verification itself by building the necessary 
calculations or comparisons using the selected and created variables and parameters. 
1 o Once the required verifications have been created and assigned to particular deals, they 

become part of the workflow assignments for that deal. When verifications are to be 
applied, they may be accessed through the main menu, through the actions list in the 
Active Deals Screens, from the deal history records. 
Definition of New Verifications 
! 5 The steps involve in setting up a new verification are ( 1 ) selecting the variable 

to be used, (2) defining any deals specific parameters which will be needed, (3) 
programming the calculations, (4) assigning importance to an abnormal result and (5) 
assigning the verification to a particular processing function end queue. 

FIGS. 15A through 15C are exemplary illustrations of data entry screens which 
20 may be used. FIG. 15A illustrates a add or edit verifications screen2020. This includes 
drop-down list boxes 2025, 2030, 2035, 2040 and 2045, and embedded sub-form 2050 
and push buttons 2055, 2060 and 2065. 

Drop-down list 2025 presents a list of existing verification names from which 
one to be modified may be selected. If a new verification is being created, a new name 
2 5 is entered in the text box for field 2025 (duplicate names are not permitted). Field 2025 

is blank by default. 
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A selection for field 203 0 is made from a drop-down list of the existing functions 
(such as Waterfall, tax - monthly, etc.) If screen 2020 is called from the Active Deals 
Screen, the default value for function field 2030 is that of the selected active deal. The 
value for queue field 2035 is selected from a drop-down list link to the master queue 
5 table and programmed to display only the queues associated with the function selected 

in field 2030. Type field 2040 is used to select how to organize the report for the 
verification will be displayed. In screen 2020, the selection for this field is "Group", 
which means that it is related to grouped or aggregated collateral information. Other 
possibilities might include "Group and Total Deal" "Class" (i.e. CUSIP number), "Class 
10 and Total Class", "Total Deal", etc. 

The entry made in field 2045 characterizes an abnormal result in terms of 
severity. Choices may include "Error" (the result is definitely incorrect), "Warning" (the 
result is probably incorrect but could be acceptable under certain circumstances) and 
"Review" (the result should be scrutinized, but may be correct). 
1 5 Sub-form 2050 displays a "Variable" column 2070 in which variable names are 

listed, and a "Description" column 2075 in which a brief description of the variable itself 
is entered. By default, sub-form 2050 is blank unless an existing verification (listed in 
Verification Name field 2025) is being modified. 

After selecting the desired variables in sub-form 205 0, any required deal specific 
20 parameters are defined. (If the user does not wish to save the work in screen 2020, 

Cancel push button 2055 may be used to return to the previous screen.) To define deal 
specific parameters, the user presses Deal Specific Parameters Push Button 2060, which 
displays a Define Deal Specific Parameters screen, an example of which is illustrated 
at 2100 in FIG. 15B. 

2 5 . Screen 2 1 00 displays a text box 2 1 05 , an embedded sub-form 2 1 1 0, a Cancel 

push button 2115, and a Continue push button 2120. When screen 2100 appears, text 
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box 2105 already contains the Verification Name as entered in field 2025 in the Add or 
Edit Verification screen 2020 (FIG. 15 A). 

Sub-form 21 10 is comprised of one or more rows such as 2125, each displaying 
the database record for one parameter, and three columns 2130, 2135 and 2140 which 
display the fields for the parameter records. Sub-form 2 1 1 0 is empty by default unless 
an existing verification is being edited. Entries for Parameters Column 2130 are 
selected from a drop-down list including the names of previously defined parameters. 
The entries for Description Column 2135 are made manually, unless an existing 
verification is being modified, in which case the previously defined descriptions are 
listed. The selection for Field Type Column 2140 is made from a drop-down list 
including entries such as "number", "text", etc. 

If the user does not wish to save the work in screen 2100, Cancel push button 
2115 may be used to return to the previous screen. If the user wishes to proceed, 
Continue push button 2120 is selected. That records the parameter definitions and the 
user is brought to the Build Calculation screen 2 150 showninFIG. 15C. Similarly, with 
reference again to FIG. 15 A, if no deal specific parameters need to be defined, the user 
proceeds directly to Build Calculation screen 21 50 by pushing Select push button 2065 . 

Screen 2150 is used to create the formula for the calculation or comparison. 
Screen 2150 is comprised of a verification text box 2155 into which displays the 
verification name from field 2125 in Add or Edit Verifications Screen 2020, a 
Composition Window 2160 and which the required computation or comparison is 
actually composed, an embedded sub-form 2165 which lists the parameters, variables, 
and operators available for defining the calculation, an OK push button 2170, a Cancel 
push button 2 1 75 and Undo push button 2180. When screen 2150 appears, Composition 
window 2160 is empty unless an existing verification is being modified. In that case, 
the previously defined calculation is displayed. 
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Embedded sub-form 2165 is comprised of a Parameters section 2185, a 
Variables section2190, and aFunctions section 2195. Parameter section 21 85 displays 
columns 2185A and 2185B which respectively list the parameter ID and descriptions 
set-up in the Define Deal Specific Parameters screen 2100. Variable section 2190 is 
also comprised of two columns 2 1 90A and 2 1 90B whichrespectively display a Variable 
ID and description for the variables selected in the Add or Edit Verification Screen 
2020. Functions section 2195 is comprised of a single column which list the operators 
available for use in composition window 21 60. The operators are accessed by a drop- 
down list including entries such as +, -, +, *, >, <, etc. 

To define the computation, the user clicks on entries from the parameters, 
Variables and Functions sections of sub-form 2 165 in the order in which they are to be 
appear. Errors are corrected by use of Undo button 2180 which erases the last item 
entered. If the user wishes to terminate without saving, Cancel button 2175 is used to 
return to the previous screen without saving. To save the calculation created, OK push 
button 2170 is used. This saves the verification and makes it available for later use, and 
returns the user to the Main Menu. 

The actual process involved in selecting the verifications for a particular deal has 
already been described in connection with set-up screen 900 shown in FIG. 7F. Specific 
values for the needed parameters are recorded using Enter Parameter Values screen 2200 
illustrated in FIG. 1 5D, accessed by selecting the Deal Specific Parameters push button 
from main verification screen 2020 (See F.g. 1 5 A) . Enter Parameter Values screen 2200 
is comprised of a text box 2205 which lists the name of the verification being developed 
from field 2025 in Add or Edit Verification screen 2020, and embedded sub-form 221 0, 
a cancel push button 2215 and an OK push button 2220. 

Sub-form 22 1 0 is comprised of column 22 1 0a and 22 1 0b which respectively list 
the parameter names and descriptions selected in the defined specific Parameters screen 
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2100 and a column 2110c which provides text boxes for the user to enter the values 
needed for the respective parameters. 

If the user does not wish to save the data entered, cancel push button 221 5 may 
used to return to screen 2020 (see FIG. 15A). OK push button 2220 stores the selected 
5 values for the parameters, and also returns the user to screen 2020. 

Running Verifications 

Automated verifications are run by selecting Run Verification push button 435 
on main menu 400 (see FIG. 6), selecting the Run Verification action from Actions list 
1535 on Active Deals Screen 1500 (see FIG. 1 1) or from the prior distribution screen 
10 described below in connection with FIG. 18 A. Access from the Main Menu will 

generally be used when not working from the Active Deals Screen. Access from the 
Active Deals Screen is most convenient if the user intends to run verifications for the 
current distribution. When it is desired to run or re-run, or simply view a verification 
for a prior distribution, access will generally be through the Prior Distribution Screen. 
15 Here, selecting a distribution pay date, e.g. by right clicking the selection, brings up a 

list of reports options including "automated verification". 

Fig. 16 illustrates an example of a Run Automated Analysis Screen 2250 from 
which the automated verification is actually run. This screen appears when the "run 
verification" function is selected in any of the three ways just described. 
2 o Run Automated Analysis screen 2250 includes a Deal ID field 2255 for which 

an entry is selected from a drop-down list linked to the Master Deals Table in the work 
flow database 244. The deal description is automatically entered in A Deal Description 
Window 2255 A based on the Deal ID value in field 2255. 

Run Automated Analysis screen 2250 also includes a function field 2260 for 
2 5 which data is selected from a drop-down list linked to the Master Functions Table, a 

First Payment Date field 2265 into which data is entered from a drop-down list of 
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completed and current payment dates derived from the Master Loan History Table and 
a Last Payment Date field 2270 for which entries are provided from a drop-down list 
also linked to the Master Loan History Table. When screen 2250 appears, fields 2165 
and 2170 are blank unless this screen was called from the Actions List in the Active 

5 Deals Screen. In that case, fields 2265 and 2270 both default to the next upcoming 
distribution date. If the Run Automated Analysis screen 2250 is accessed from the Main 
Menu 400 or the Prior Distributions List, the fields are blank by default. 

When the necessary selections have been made, the user may press Run push 
button 2275. At that point, all relevant reports, as determined by the current queue and 

L 0 status milestone for the deal are run. (Individual verifications may not be selected.) If 
a range of dates has been indicated in fields 2265 and 2170, the verifications for that 
range of dates are run. If no last payment date is selected, then verifications for 
distributions prior to the upcoming current distribution are not run. 

When the reports have been run, all are available in sequence for viewing on the 

1 5 user's screen. (The list may be scrolled, if necessary.) The reports may also be printed 
from the viewing screens. When the user has completed viewing the verification 
reports, the screen is closed in the normal manner. 

If the user does not wish to complete running the verifications, cancel push 
button 2280 may be used to return to the screen from which Run Automated Analysis 

2 0 screen 2250 was accessed. 

Verification Reports 

For convenience, all verification reports are preferably displayed in a standard 
format. That format might include, for example, standard headers on every page 
showing the Deal ID and Descriptive Name, the date range for the verifications, and the 

2 5 current function, queue, and upcoming distribution, for the particular deal. Following 

the header, the report may display the title of the verification, the queue to which the 
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verification applied, the data type according to which the report is organized, and the 
period ending date to which the specific report applies. Following this, there may be a 
listing of the variables and parameters, a word formula representation of the calculation 
and the actual results organized according to the data type listing previously referred to, 
5 the result of the computation, and the severity category. An example of a report 
formatted as described above is shown at 2300 in Fig. 17. 
Restatements 

On those occasions when a problem with the data or processing for a particular 
payment cycle is not detected before the payment has been made, corrections are made 

10 by "restating" the waterfall and monthly tax processing for that particular payment, and 

reprocessing any other affected subsequent payments. A restatement may be necessary, 
for example, if it is discovered that an issuer has provided incorrect information. 

As implemented according to the present invention, the actions involved in a 
restatement are (a) storing an exact backup image of the data for the distribution to be 

1 5 restated in various database files in workflow data base 244, (b) deleting the processing 

results for the distribution being restated and for all subsequent distributions, (c) 
rerunning the end of cycle processing logic as previously described for the period 
preceding the one being restated, and (d) requiring the user to enter a comment 
explaining the need for the restatement. The specific events and operations will be 

2 0 described below for each step of the restatement process. 

Initiating a Restatement 

Generally, a process to be restated is designated by highlighting a particular deal 
in Active Deals Screen 1500 and then selecting Restatement from Actions List 1535. 
This displays a Prior Processing Screen, an example of which is shown at 2500 in Fig. 

2 5 18A. Prior Processing Screen 2500 displays a Deal ID field 2505, a Deal Description 

field 25 1 0, and a Function field 2515. 
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The entry for field 2505 is selected from a drop-down list linked to the Master 
Deals Table in ASAP database 250 (see Fig. 4). Deal Description Field 2510 is 
automatically filled in based on the selection for Deal ID field 2505. The entry for 
Function field 2515 is selected from a drop-down list linked to the Master Functions 

5 Table in Workflow Database 244. 

Fields 2505, 2510 and 2515 function as a query form. An embedded report sub- 
form 2520 displays the function, the applicable period, and the date and time that the 
processing activity for that period was completed in respective columns 2525a-2525c 
for the data returned by the query. 

L 0 When screen 2500 appears, none of the rows 2530 in sub-form 2520 are 

highlighted. To proceed, the user highlights one of rows 2530, which causes an 
Options screen such as illustrated at 2550 in Fig. 18B to pop up over screen 2500. 
Options screen 2550 displays the Restatement options available for the deal and 
functions selected. 

15 Available options include Reports, Restate Non-Financial, Restate Financial, 

Comments, View Comments, and Exit. These are displayed in respective lines 2555a, 
2555b, 2555c, 2555e, 2555f and 2555h. More than one restatement for a particular 
distribution may be performed as part of the correction process. In that case, additional 
restated versions will be available, and the Options sub-menu on screen 2550 will also 

2 0 list Select Prior Version on line 2555d and Restore From Prior Version on line 2555g. 

Selecting Reports (line 2555a) accesses a pop-up sub-menu of reports available 
for the distribution under review. Highlighting one of the listed reports displays that 
report for viewing and printing. This option might be exercised as part of the analyst's 
effort to study and correct the problem under investigation. 

25 Selecting Comments line (2555e) from Options screen 2550 brings up 

Comments Screen 1 5 90 described above in connection with FIG. 1 2C. Selecting View 
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Comments (line 2555f) brings up Comment History List 1550 described in connection 
with Fig. 12B. Selecting Exit (line 2555g) returns the user to active deals screen 1 500. 

The Select Prior Version option on screen 2550 brings up a Restated Processes 
sub-menu, an example of which is shown at 2600 in FIG. 19 A. Screen 2600 displays 
5 a Deal ID field 2605 , a Deal Description field 2610, a Function field 2615 and a Period 
Ending field 2620, all of which are accessed from drop-down lists linked to tables in 
Workflow Database 240 and ASAP Database 250. (The data objects for fields 2605 in 
2610 may be programmed so that making a selection from the drop-down list for one 
field results in corresponding data being automatically entered in the other field. Since 

1 0 the restatement function is applicable only to waterfall and monthly tax processing, the 
selections available for field 2620 are limited to these two. The selections for field 2625 
include all of the pay dates for the deal selected in field 2605. 

Fields 2605 through 2620 serve as a query. The results, in terms of the date and 
time the various restatements were completed, is reported in embedded sub - form 2625 . 

1 5 Right clicking on one of the items listed in sub-form 2625 brings up a pop-up Options 

List, an example of which is illustrated at 2650 in FIG. 19B. 

Available options may include Reports, line 2655a, Make Version of Record, 
line 2655b, Comments, line 2655c, and Exit, line 2655d. Selecting the Reports option 
brings up a list of reports of previous restatements for viewing. Selecting the Make 

2 0 Version of Record option designates the most recent restated version as the "official" 
or correct version. Selecting the Comments option brings up the comment entry screen 
previously described. The Exit option returns the user to the Active Deals Screen 1 1 00. 

A restatement may involve the financial and/or non-financial aspects of a 
distribution. Restatements are initiated by selecting Re-state Non-Financial at line 

2 5 2555b or Restate Financial at line 2555c in Options Screen 2550 (FIG. 1 8B). A message 
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such as "Are you sure you want to re-state..." may be displayed for confirmation before 
a restatement is actually initiated. 

When a restatement is performed, the status records for the deal are updated in 
Workflow Database 244 and a backup copy of all of the information related to the 
5 distribution being restated is saved in workflow database 244. This reduces the need to 

re-enter information and allows fast and easy correction of minor errors. Also, the prior 
distribution reports for the distribution being restated are maintained in the back up for 
payment information. This assures that workflow tracking integrity is not lost and 
allows prior reports to be printed as needed. Restated information for a payment is not 
10 automatically sent to RTP subsystem 220 (see FIGS.3 and 4) but is designated for 

manual entry. 

The nature of the problem giving rise to the restatement will determine the effect 
on the workflow resulting from the restatement. For example, referring back to FIG. 
5B ? if a non-financial restatement is required for a May distribution (step 292d), and the 

1 5 current distribution being processed is for the December payment (step 292e), only step 

992d will have to be repeated. The workflow remains unchanged, i.e., waterfall 
processing for December, step 292e, tax processing for November, step 25 6e, and tax 
processing for the fourth quarter, step 260d, may continue. 

In contrast, if the December distribution is being processed, and financial 

2 0 restatement is required for May at step 292d, all processing steps for May and all 
subsequent months, i.e. the May through December waterfall processing, the April 
through November monthly tax processing, the second, third and fourth quarter tax 
processing and the annual tax processing will have to be repeated. In that event the 
waterfall and tax processing queues will revert to the May waterfall distribution, and the 

2 5 April monthly and the second-quarter tax processing. 
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A tax restatement does not affect waterfall processing, but does require tax re- 
processing for the restated month and all subsequent months. Thus, for example, if 
waterfall processing is being performed for the December payment, and monthly tax 
processing for April (step 256d) must be restated, then the monthly tax computations for 
June through November, for the second, third and fourth quarters and for the year must 
be re-processed. The workflow for waterfall processing remains unchanged, but the tax 
processing queues are returned to the month of May and the second-quarter. 

As will be appreciated from the above description, the invention provides an 
effective solution to workflow management for complex financial transactions involving 
many deals and data which changes on a frequent basis. It also permits modification of 
the data structures as needed to accommodate evolutionary changes in the financial 
structures of the deals being handled. In the preferred embodiment, the invention is 
implemented using a relational database management system on a computer network 
organized on a client-server model. It should be understood, however, that other system 
architecture and other programming implementations providing the workflow 
management and other capabilities described is considered to be within the scope of the 
invention. In addition, other variations and modifications and other uses will be apparent 
to those skilled in the art in light of the description of the invention. It is intended, 
therefore, that the present invention be limited not by the specific disclosure herein, but 
only by the appended claims. 
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WE CLAIM 

1. A computerized method of workflow management for a trustee handling a 
plurality of securitization transactions comprising the steps of: 

recording deal setup information in an electronic database including information 
5 related to the structure of each of the securitizations; 

recording workflow status information for each of the securitizations in the 

electronic database; 

periodically receiving asset level data transmitted by at least one asset manager; 

aggregating the asset level data; 
10 transmitting the aggregated asset level data electronically to a workflow 

management software module; 

providing an active deals display generated by the workflow management 
software module, based at least in part on the recorded deal setup information and the 
recorded workflow status information, which display provides access to workflow status 
1 5 information for particular securitizations, provides prompts for a user as to work which 
is to be done with respect thereto, and permits the user to initiate actions required for 
performance of the trustee's duties; and 

updating the recorded workflow status information for the securitizations based 
on work performed with respect thereto. 

2. The method described in claim 1, wherein the steps are performed under 
control of the workflow management software module. 

3. The method described in claim 1 further including the step of electronically 
transmitting data concerning payments due investors in the securitization from the 



00460185.1 



-65- 



workflow management software module to a software module which processes 
payments to the investors based on the transmitted data. 

4. The method described in claim 3, further including the step of electronically 
disseminating reports and other data compilations upon completion of the payment 
processing. 

5. The method described in claim 1 further including the step of calculating 
waterfall payments due investors in the securitizations on a periodic basis in accordance 
with the deal structure and the aggregated asset level data; 

6. The method described in claim 5, further including the step of performing 
calculations of taxes owed by the investors on the waterfall payments based on the 
waterfall calculations. 

7. The method described in claim 1, in which the step of aggregating the asset 
level data is performed by a first software module separate from the workflow 
management software module. 

8. The method described in claim 7, further including the step of providing an 
interface which maps the data produced by the first software module for compatibility 
with the workflow management software module. 

9. The method described in claim 1 , in which the workflow status information 
is displayed in terms of basic functions associated with management of the 
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securitization, workflow events associated with the basic functions and milestones 
associated with the workflow events. 

10. The method described in claim 9, in which the basic functions include 
waterfall processing and tax processing. 

1 1 . The method described in claim 1 0, in which the workflow events associated 
with the waterfall processing function include a Data Aggregation queue, a Data 
Preparation queue, aReady for Waterfall Processing queue, a Waterfall Approval queue 
and a Payment queue. 

12. The method described in claim 1 1 , in which the milestones associated with 
the Data Aggregation queue include Not Ready, Data Received and Denied. 

13. The method described in claim 1 2, further including the step of changing the 
workflow status of a securitization in waterfall processing to the Data Aggregation 
queue and Not Ready status when a previous payment cycle has been completed. 

14. The method described in claim 1 3, further including the step of changing the 
workflow status of a securitization in the Data Aggregation queue and the Not Ready 
milestone to Data Received status when asset level data for a new waterfall processing 
cycle is received. 

15. The method described in claim 14, further including the step of changing the 
workflow status of a securitization from Not Ready to Data Received status in response 
to a user command. 
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1 6. The method described in claim 12, further including the step of changing the 
workflow status of a securitization in the Data Received milestone to the Data 
Preparation Queue and the Tape Run milestone if the aggregated asset level data is ready 
for further processing, or is transferred to Data Denied status in the Data Aggregation 

5 queue if the aggregated asset level data is incomplete, inaccurate or otherwise not ready 
for further processing. 

17. The method described in claim 16, further including the steps of: 
permitting a user to review the aggregated data and to approve or rej ect the data, 

and 

changing the workflow status of the securitization to the Data Preparation queue 
5 and the Tape Run milestone if the user approves the data, or to the Data Denied status 

in the Data Aggregation queue if the user rejects the data. 

18. The method described in claim 17, further including the step of requiring 
entry of supporting comments by the user into a data entry screen before changing the 
status to Data Denied if the user has rejected the data. 

19. The method described in claim 1 6, further including returning the workflow 
status of a securitization in the Data Denied milestone to Data Received status when 
new or corrected aggregated data is received. 

20. The method described in claim 1 1 , in which the milestones associated with 
the Data Preparation queue include Not Ready, Tape Run, Loan Level Processed and 
Denied. 
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2 1 . The method described in claim 20, wherein, for a securitization in the Data 
Preparation queue and the Not Ready milestone, the actions which the user is permitted 
to initiate include: 

an Approve action; and 
5 a Data Entry action, 

22. The method described in claim 21, further including the step of: 
changing the workflow status to the Ready for Waterfall Processing queue and 

the Ready milestone in response to an Approve action. 

23. The method described in claim 21, further including the step of: 
making a data entry screen available to the user when a Data Entry action is 

initiated. 

24. The method described in claim 20, further including the step of changing the 
workflow status of a securitization in the Data Preparation queue and the Tape Run 
milestone to the Asset Level Processed status in the Data Preparation queue by the 
workflow management software module when the data aggregation operation has been 

5 completed, or to the Data Aggregation queue and Data Denied status in response to a 
user command. 

25. The method described in claim 24, further including the steps, for a 
securitization in the Data Preparation queue and the Asset Level Processed milestone, 
of: 

permitting the user to review the aggregated asset level data, and to accept or 
5 reject the data according to predefined criteria; and 
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changing the workflow status of the securitization to the Ready For Waterfall 
Processing queue and the Ready status if the user approves the data, or to the Data 
Denied status in the Data Prep queue if the data is rejected. 

26. The method described in claim 20, wherein, for a securitization in the Data 
Preparation queue and the Denied milestone, the actions which the user is permitted to 
initiate include; 

a Deny to Asset Level Aggregation action; 
5 an Enter Data action; and 

an Aggregate action. 

27. The method described in claim 26, further including the step of changing the 
workflow status to the Asset Level Aggregation queue and the Denied status when the 
Deny to Asset Level Aggregation action is taken. 

28. The method described in claim 26, further including the step of making a 
data entry screen available to the user when the 

Enter Data action is initiated. 

29. The method described in claim 26, further including the steps of: 
performing an asset level data aggregation when the Aggregate action is 

initiated; and 

changing the workflow status to Loan Level Processed in the Data Preparation 
5 queue when the asset level data aggregation has been completed. 
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30. The method described in claim 1 1, in which the milestones associated with 
the Ready for Waterfall Processing queue include Ready and Denied. 

3 1 . The method described in claim 30, wherein, for a securitization in the Ready 
for Waterfall Processing queue and Ready status, the actions which a user is permitted 
to initiate include: 

a Deny action; 

a Run Waterfall action; 

an Enter Data action; 

an Add Special Headers/Footers action; and 
an Add Asset Level Information action. 

32. The method described in claim 3 1 , further including the step of returning the 
workflow status of the securitization to the Data Ready Queue and Data Denied 
milestone when a Deny action is selected. 

33. The method described in claim 31, when the Run Waterfall action is 
selected, further including the steps of: 

providing the asset level data to a third software module for waterfall processing; 

and 

when the waterfall processing has been completed, changing the workflow status 
to the Waterfall Approval queue and Ready milestone. 

34. The method described in claim 3 1 ? when the Enter Data, the Add Special 
Headers/Footers or the Add Asset Level Information actions are selected, further 
including the steps of: 



-71- 



making data entry screens accessible to the user; and 
5 after data entry has been completed, returning the user to the list of permitted 

actions. 



35. The method described in claim 30, wherein, for a securitization in the Ready 
for Waterfall Processing queue and Denied status, the actions which a user is permitted 
to initiate include: 

a Deny action; and 
5 a Run Waterfall action. 

36. The method described in claim 35, further including the step of: 
changing the workflow status to the Data Ready queue and Data Denied status 

when a Deny action is initiated. 

37. The method described in claim 35, when a Run Waterfall action is initiated, 
further including the steps of: 

providing the asset level data to a third software module for waterfall processing; 

and 

5 thereafter, when the waterfall processing is completed, changing the workflow 

status to the Waterfall Approval queue and Ready status. 

38. The method described in claim 1 1, in which at least a Ready milestone is 
associated with the Waterfall Approval queue. 

39. The method described in claim 38, wherein, for a securitization in the 
Waterfall Approval queue, further including the steps of: 
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performing at least one predefined test under control of the user to verify the 
accuracy of the waterfall calculations; 
5 permitting the user to approve the data if the test is passed; and 

in response to approval of the data by the user, changing the workflow status to 
the Payment queue and Final Approval status. 

40. The method described in claim 39, further including the steps of: 
permitting the user to select the Deny action if the verification test is not passed; 

and 

in response to selection of the Deny action, changing the workflow status to a 
5 predetermined status level in an earlier queue. 

41. The method described in claim 38, wherein, for a securitization in the 
Waterfall Approval queue, further including the steps of: 

performing a series of predefined tests to verify the accuracy of the waterfall 
calculations; and 

5 if the tests are passed, changing the workflow status to the Payment queue and 

Final Approval status; or 

if the tests are not passed, changing the workflow status to a predetermined 
queue and milestone as a function of which of the tests in the series was not passed. 

42. The method described in claim 1 1 , in which the milestones associated with 
the Payment queue include Final Approval, Received by Payment System, and Payment 
Made. 
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43. The method described in claim 42, for a securitization in the Payment queue 
and Final Approval status, further including the steps of: 

changing the workflow status to the Received by Payment Systems milestone; 

and 

5 providing the waterfall data to a payment processing software module for 

payment processing. 

44. The method described in claim 42, for a securitization in the Payment queue 
and the Received by Payment Systems milestone, further including the step of: 

when the payment processing is complete, changing the workflow status to the 
Payment Made milestone. 

45 . The method described in claim 42, for a securitization in the Payment queue 
and the Payment Made milestone, further including the steps of: 

selecting the next waterfall distribution date; and 

the workflow status to the Data Aggregation queue and the Not Ready milestone. 

46. The method described in claim 1 0, in which the workflow events associated 
with the tax processing function include a Ready for Tax Processing queue, a Tax 
Approvals queue and a Tax Reports queue. 

47. The method described in claim 46, wherein, for a securitization in tax 
processing, in the Ready for Tax Processing queue, the actions which the user is 
permitted to initiate irrespective of the milestone, include: 

an Enter Data action; and 
5 a Run Tax Processing action. 
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48. The method described in claim 47, further including the step of making a 
tax data entry screen accessible to the user if the Enter Data action is selected. 

49. The method described in claim 47, further including the steps of: 
making the waterfall data available to a tax processing software module for 

computation of taxes due on the waterfall payments; and 

after the tax computations have been completed, changing the workflow status 
to the Tax Approval queue and Ready status. 

50. The method described in claim 49, further including the step of performing 
tax computations for each of the waterfall payment periods. 

5 1 . The method described in claim 46, wherein, for a securitization in the Tax 
Approval queue, and the Ready milestone, the actions which the user is permitted to 
initiate include: 

an Approval-Monthly action; and 
an Approval- Annual action. 

52. The method described in claim 51, further including the step of: 
applying at least one verification test to the waterfall payment tax computations 

if the Approval-Monthly action is selected. 

53. The method described in claim 51, if the Approval-Quarterly action is 
selected, further including the steps of: combining the monthly waterfall payment tax 
data for the respective securitizations; 
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applying at least one verification test to the combined data; and 
upon successful verification of the tax computations, changing the workflow 
status of the securitization to the Mail Reports queue and Ready status. 

54. The method described in claim 51, if the Approval- Annual action is 
selected, further including the steps of: 

combining the quarterly tax data for the respective securitizations; 
applying at least one verification test to the combined data; and 
upon successful verification of the tax computations, changing the workflow 
status of the securitization to the Mail Reports queue and Ready status. 

55. The method described in claim 51, wherein, for a securitization in the Tax 
Approval queue, and the Ready milestone, the actions which the user is permitted to 
initiate further include: 

a Deny action; and 
a Tax Reports action. 

56. The method described in claim 55 , further including the step of changing the 
workflow status of the securitization to a predetermined queue and milestone based on 
the structure of the specific securitization if the Deny action is selected. 

57. The method described in claim 55, if the Tax Reports action is selected, 
further including the steps of: 

making a list of tax reports accessible to the user; 

permitting the user to select of one or more reports; and 

activating a tax processing software module to generate the selected reports. 
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58. The method described in claim 55, wherein, for a securitization in the Tax 
Reports queue, the actions which the user is permitted to initiate include: 

a Mail action; and 
a Tax Reports. 

59. The method described in claim 58, if the Mail action is selected; further 

including the steps of: 

activating the tax processing software module to print quarterly and annual tax 

reports previously generated; 
5 identifying the next tax processing cycle; and 

changing the workflow status to the Ready for Tax Processing queue and Ready 
status for the identified period. 

60. The method described in claim 58, if the Tax Reports action is selected; 
further including the steps of: 

permitting tax reports to be selected by the user for generation; and 
generating the selected reports. 

61 . The method described in claim 46, in which the milestones associated with 
the Ready for Tax Processing queue include Ready and Denied. 

62. The method described in claim 46, in which the milestones associated with 
the Tax Approvals queue include Ready and Denied. 
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63. The method described in claim 46, in which at least a Ready milestone is 
associated with the Tax Reports queue. 

64. The method described in claim 1, farther including the steps of: generating 
a selection screen having a plurality of active elements thereon; and 

permitting a user may initiate functions by selection of the active elements. 

65. The method described in claim 64, wherein the functions which the user is 
permitted to initiate include one or more of: 

invoking an active deals display; 

viewing and changing index data used for waterfall payment calculations; 
5 viewing and changing details of the deal structures for the securitizations; 

viewing and changing information concerning those to whom responsibility may 
be assigned for particular securitizations; 

viewing and changing information concerning particular assignments; 
viewing and changing information concerning other individuals and entities 
1 0 interested in the securitizations or having information relevant thereto; 

viewing and changing information related to database structure; 

setting up and performing data verifications; 

viewing historical data concerning the securitizations; and 

establishing and updating security levels for access to information by users; 

66. The method described in claim 1, wherein the stepup recording set up 
information includes: 
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allowing a user to select pertinent information concerning a particular 
securitization for entry in fields on a plurality of data entry screens from lists stored in 
5 at least one database record; 

automatically filling in data in additional fields based on a selection made for at 
least one other field; and 

allowing the user to create records for new information not contained in an 
existing database record by entering data in the fields of at least one data entry screen 
1 0 for that record. 

67. The method described in claim 66, wherein the step of recording set up 
information further includes permitting the user to edit existing database records by 
entering new information in the fields of at least one data entry screen for that record. 

68. The method described in claim 66, further including the step of allowing the 
user to make selections for at least some of the fields in a data entry screen from drop- 
down lists created from stored database records. 

69. The method described in claim 68, further including the step of determining 
the content of at least one of the drop-down lists as a function of the data selection 
made for another field. 

70. The method described in claim 68, further including the step of scrolling at 
least some of the drop-down lists on the basis of partial entries in text boxes for the lists. 

71. The method described in claim 1, wherein the step of recording set up 
information includes: 



00460185.1 



-79- 



allowing a user to access and enter data into the fields of a series of data input 
screens, each screen providing for entry of a particular type of data related to the 
5 particular securitization; and storing the data entered by the user in the database in 
response to a save command from the user. 

72. The method described in claim 71, further including the step of permitting 
the user to access specific data entry screens by selecting tabs appearing on all of the 
screens in the series. 

73. The method described in claim 71, further including the step of displaying 
tables in at least some of the data input screens, the tables having a plurality of rows, 
each row representing a data base record and a plurality of columns, each column row 
representing the fields of the displayed records. 

74. The method described in claim 73, further including the step of 
automatically filling at least some of the fields of a particular database record based on 
selection by the user of data for another field for that record from a list. 

75. The method described in claim 71, further including the step of permitting 
the user access to a Setup data screen, an Output data screen, a Contacts data screen, a 
Steps data screen, a Quality Control data screen, an Inputs data screen and a 
Header/Footer data screen. 

76. The method described in claim 75, further including the step of permitting 
the user to enter data in fields of the Setup data screens identifying a particular 

00460185.1 



-80- 



securitization, and at least the basic functions to be performed in managing the 
particular securitization. 

77. The method described in claim 76, further including the step of permitting 
the user to enter data in fields, the Setup data entry screens identifying the frequency 
with which the basic functions are to be performed from a list of possible frequencies. 

78. The method described in claim 75, further including the step of permitting 
the user to enter data in fields of the Output data entry screens which specify the 
distribution media, the subject matter, the format, the release date, recipient information 
and the title of each report to be created for a particular securitization. 

79. The method described in claim 75, further including the step of permitting 
the user to enter data in fields of the Contacts data entry screens from drop-down lists 
which exclude employees of the trustee. 

80. The method described in claim 75, wherein the workflow status of the 

securitizations is recorded in terms of basic functions to be performed, processing 

queues for each basic function and progress milestones for each queue, and further 

including the steps of: 

permitting a user to identify a particular securitization and a basic function on 

the Steps data entry screen; 

displaying a table in the Steps data input screens, the table having a plurality of 
rows, each representing a data base record for a specific queue and a plurality of 
columns, each representing the fields of the displayed records. 
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8 1 . The method described in claim 80, wherein the fields for each queue record 
include at least a queue identification field, a field identifying the individual responsible 
for performance of actions associated with the queue and a field specifying the day of 
the month on which the action is to be taken. 

82. The method described in claim 81, further including the step of permitting 
selection of the entry for the queue identification field from a drop-down list populated 
from a database record in accordance with a basic function selected by the user. 

83. The method described in claim 82, further including the step of 
populating the queue identification drop-down list in a predetermined order representing 
the expected processing order for the selected basic function. 

84. The method described in claim 82, wherein the step of permitting queue 
selection from the queue identification drop-down list includes permitting concurrent 
selection of more than one item from the list. 

85. The method described in claim 81, further including the step of permitting 
selection of a Deny field for each queue record which specifies a workflow path change 
in case data is disapproved at a particular queue. 

86. The method described in claim 85, wherein the workflow path change is 
specified by flagging the Deny field, and wherein a data disapproval in a queue for 
which the Deny field has been flagged returns the status of the securitization to the 
nearest queue above in the processing order for which the Deny field has also been 

5 flagged, except that if the disapproval takes place in a queue for which the Deny field 
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has been flagged, the status is returned to the immediately previous queue, irrespective 
of flagging of the Deny field. 

87. The method described in claim 75, further including the steps of: 
displaying a drop-down list of predefined data verification tests in the Quality 

Control data entry screens; 

displaying tables in the Quality Control data entry screens, the table 
5 having a plurality of rows, each representing a data base record concerning use of a data 
verification test; and 

permitting a user to select at least one verification test from the drop-down list, 
and to specify a queue and milestone at which the selected verification test is to be 
performed, 

88. The method described in claim 87, wherein the step of permitting 
verification test selection from the verification identification drop-down list includes 
permitting concurrent selection of more than one item from the list. 

89. The method described in claim 75, farther including the steps of: 
permitting a user to identify a particular securitization and a basic function on 

the Steps data entry screen; 

displaying a table in the Steps data input screens, the table having a plurality of 
5 rows, each representing a data base record for a specific queue and a plurality of 
columns, each representing the fields of the displayed records. 
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90. The method described in claim 75, wherein the aggregated asset level data 
is transmitted in the form of at least one database record having a first structure, and 
further including the step of: 

permitting a user to remap fields of the first database structure in the Inputs data 
5 entry screen to correspond to fields of a second database structure used in performing 
the waterfall payment calculations. 

9L The method described in claim 90, further including the steps of: 
displaying two tables in side-by-side relation in the Inputs data entry screen, the 

tables having a plurality of aligned rows, with the rows of the first table permitting 

selection of fields of the first data base structure, and the rows of the second table 
5 permitting selection of fields in the second database structure; and 

permitting the user to populate respective aligned rows of the two tables with 

data to identify corresponding fields in the two database structures for the particular 

securitization. 

92. The method described in claim 91, wherein the data for the fields are 
selected from drop-down lists of the fields in the respective database structures. 

93. The method described in claim 92, further including the steps of: 
permitting the user to select a previously created mapping as a template for a 

new mapping; and 

populating the rows of the two tables to reflect the previously created mapping. 
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94. The method described in claim 90, further including the step of: 
permitting the user to select a previously created mapping as a template for a 

new mapping. 

95. The method described in claim 75, further including the steps of: 
permitting the user to identify a particular securitization in the Header/Footer 

data entry screen; and 

permitting the user to specify in the Header/Footer data entry screen, the text and 
5 page location of headers and footers to be used in periodic reports for the specified 
securitization. 

96. The method described in claim 74, further including the step of permitting 
a user to enter data in an index rate data entry screen which identifies a particular 
securitization, and specifies an index and the source thereof for use in the waterfall 
calculations for the particular securitization. 

97. The method described in claim 96, further including the step of permitting 
a user to enter dates in the index rate data entry screen for which values of the specified 
index are to be determined in connection with the particular securitization. 

98. The method described in claim 74, further including the step of permitting 
a user to enter data in a global staff/contact data entry screen concerning changes which 
affect a plurality of securitizations. 
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99. The method described in claim 98, further including the steps of: 
permitting the user to formulate a database query on the global staff/contact data 

entry screen; and 

providing a report thereon based on variables included in the query. 

100. The method described in claim 99, further including the steps of: 
permitting the user to formulate the query in terms of the value of at least one 

variable including queue type, previous staff person or contact, and new staff person or 
contact; and 

5 providing a report which lists all securitizations and queues corresponding to the 

variable values included in the query. 

101 . The method described in claim 74, further including the step of: 
permitting a user to identify on a privilege level data entry screen, roles of 

individuals having responsibility for performing the trustee's duties, and to specify 
levels of data access for data viewing and modification for the established queues and 
5 milestones. 

102. The method described in claim 1, further including the steps of: 
permitting the user to formulate a database query on the active deals display 

screen; and 

providing a report thereon based on variables included in the query. 
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103. The method described in claim 102, further including the steps of: 
permitting the user to formulate the query in terms of the value of at least one 

variable including user name, queue type, securitization name, basic function, and need 

for current activity; 

5 providing a report which lists at least the securitizations, basic functions and 

workflow status for listed securitizations corresponding to the variable values included 
in the query. 



104. The method described in claim 1, in which the active deals screen is 
provided with a table thereon, the table including rows each of which contains workflow 
status information concerning a particular securitization, and further including the steps 
of: 

5 permitting a user to select a specific securitization; and thereafter presenting the 

user a pop-up selection list from which specific actions applicable to the 
workflow status of the selected securitization may be initiated. 

1 05. The method described in claim 104, wherein at least some actions available 
in some of the pop-up selection lists require supporting documentation, and further 
including the steps of: 

presenting the user with a data entry screen for providing the required 
5 documentation; and 

carrying out the selected action after the supporting documentation has been 
provided. 
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106. The method described in claim 1, further including the step of permitting 
a user to manually enter information required for waterfall payment and tax processing 
which is not provided as part of the aggregated asset level data. 

107. The method described in claim 1, further including the steps of: 
permitting a user to set up data verification tests as part of the deal setup 

information, and to specify queues and milestones at which the tests are to be applied; 
and 

prompting the user on the active deals screen when predefined verification tests 
are to be performed. 

108. The method described in claim 107, further including the step of: 
permitting the user to customize pre-existing verification tests for reuse. 

109. The method described in claim 108, wherein the step of setting up a 
verification includes the steps of: 

selecting the variable to be used; 

defining specific parameters needed for a particular securitization; 
programming the necessary calculations; 
assigning importance to an abnormal result; and 
assigning the verification to a basic function and queue. 

1 10. The method described in claim 109, further including the steps of: 
providing at least one data entry screen for use in formulating verifications; and 
providing drop-down selection lists for selecting pre-existing verifications for 

modification, for specifying the basic function and queue at which the verification is to 
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be performed, for selecting variables, parameters and values thereof, and for specifying 
the workflow consequences of an abnormal result. 

111. The method described in claim 1 10, further including the step of: 
providing a text box for use in creating a formula to be performed as the 

verification. 

112. The method described in claim 1 10, further including the step of: 
permitting the creation of the formula using words and mathematical operators. 

113. A computerized method of workflow management for concurrently 
handling a plurality of complex multiple step projects, the method comprising the 
following steps, all under control of workflow management software: 

creating in a database, a project setup record which uniquely characterizes each 

project; 

recording workflow status information for the projects in a database; 

providing access for a user to a computer generated workflow status display 
generated at least in part from the project setup information records and the workflow 
status information, which display permits access to workflow status for selected 
projects, provides prompts for the user as to work which is to be done with respect 
thereto, and permits the user to initiate actions; and 

automatically updating the workflow status record in the database whenever 
there is a change in the status of a project resulting from action initiated by the user. 
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1 14. The method described in claim 113 further including the steps of: 
automatically performing required tasks according to the information stored in 

the project setup record for the project; and 

automatically updating the workflow status record in the database whenever 
there is a change in the status of a project resulting from automatic performance of 
required tasks. 

115. The method described in claim 113, wherein the step of recording 
workflow status information includes the step of entering information in database fields 
which identify basic functions involved in executing the project, workflow queues 
associated with the basic functions andmilestones associated with the workflow queues. 

1 1 6. The method described in claim 95, wherein the information entered in the 
fields is derived, at least in part, from pre-stored lists. 

117. The method described in claim 94 further including the step of creating the 
project setup records at least in part from lists of pre-stored information. 

118. The method described in claim 1 13, further including the steps of: 
receiving information required for execution of the projects electronically from 

a source external to the workflow management software; 

electronically transmitting information for performance of data processing tasks 
to at least one module external to the workflow management software; and 

electronically receiving data from the external module representing the result of 
the data processing tasks performed. 



-90- 



119. The method described in claim 118, wherein the information from the 
external source is in the form of database records, and further including the step of 
providing an interface which remaps the database structure of the information for 
compatibility with the workflow management software. 

120. The method described in claim 113, further including the step of 
electronically disseminating reports and other data compilations concerning the 
execution of the project. 

121. The method described in claim 113, in which the status information is 
displayed in terms of basic functions associated with management of the project, 
workflow queues associated with the basic functions and milestones associated with the 
workflow queues. 

122. The method described in claim 113, further including the steps of: 
prompting the user to review data at predetermined stages of the projects; 
permitting the user to take action based on the review; and 

changing the workflow status of the projects in accordance with the actions 

5 taken. 

123. The method described in claim 122, further including the step ofrequiring 
entry of supporting information by the user on a data entry screen before changing the 
workflow status of a project, for at least some actions taken by the user; and 

storing the supporting information in a database record. 
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124. The method described in claim 113, wherein the workflow status display 
presents a list of projects, and wherein the method further includes the step of providing 
an actions list containing the actions available to the user as a pop-up selection screen 
on the active deals display which appears when a listed project is selected. 

1 25 . The method described in claim 113, further including the step of generating 
a selection screen having a plurality of active elements thereon from which a user may 
initiate tasks by selection of the active elements. 

1 26. The method described in claim 113, wherein the step of creating the project 
setup record includes: 

allowing a user to select pertinent information concerning a particular project 
from lists stored in at least one database record for entry in fields on a plurality of data 
5 entry screens; 

automatically filling in data in additional fields based on a selection made for 

another field; and 

allowing the user to create records for new information not contained in an 
existing database record by entering data in the fields of at least one data entry screen. 

127. The method described in claim 126, wherein the step of creating the project 
setup record further includes permitting the user to edit existing database records by 
entering new information in the fields of at least one data entry screen. 

128. The method described in claim 127, further including the step of allowing 
the user to make selections for at least some of the fields in a data entry screen from 
drop-down lists created from stored database records. 
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129. The method described in claim 128, further including the step of 
determining the content of at least one of the lists as a function of a data selection made 
for another field. 

130. The method described in claim 129, further including the step of scrolling 
at least some of the lists on the basis of partial entries in text boxes for the lists. 

13 L The method described in claim 1 1 3, wherein the step of creating the project 
set up record includes the steps of: 

allowing a user to access and enter data into the fields of a series of data input 
screens, each screen providing for entry of a particular type of data related to the project; 
5 and 

storing the data entered by the user in the database in response to a save 
command. 

1 32. The method described in claim 131, further including the step of permitting 
the user to access specific data entry screens by selecting tabs appearing on all of the 
screens in the series. 

133. The method described in claim 113, wherein the step of creating the proj ect 
setup record further includes the step of permitting the user to specify workflow path 
changes in accordance with predetermined contingencies. 

134. The method described in claim 115, further including the steps of: 
permitting the user to access a list of predefined data verification tests; and 
permitting a user to select at least one verification test from the list; and 
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permitting the user to specify a queue and milestone at which the selected 
5 verification test is to be performed. 

135. The method described in claim 113, wherein the step of permitting 
verification test selection includes permitting concurrent selection of more than one item 
from the list. 

136. The method described in claim 94, wherein the step of providing access to 
the workflow status display further includes the steps of: 

permitting the user to formulate a database query on the display screen from 
fields representing variables for the query; and 
5 providing a report thereon based on variables included in the query. 

137. The method described in claim 95, further including the step of: 
permitting a user to specify roles of individuals having responsibility for 

executing the project, and to specify levels of data access for data viewing and 
modification for the recorded queues and milestones. 

138. The method described in claim 95, wherein the step of creating the project 
set up record includes: 

permitting a user to set up data verification tests as part of the deal setup 
information, and to specify queues and milestones at which the tests are to be applied. 

139. The method described in claim 138, further including the step of: 
permitting the user to customize pre-existing verification tests for reuse. 
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140. The method described in claim 139, wherein the step of setting up a 
verification includes the steps of: 

selecting variable to be used; 
defining specific parameters for the test; 
5 programming necessary calculations; 

assigning importance to an abnormal result; and 
assigning the verification to a basic function and queue. 

141 . The method described in claim 140, further including the steps of: 
providing at least one data entry screen for use in formulating verifications; and 
providing selection lists for specifying pre-existing verifications for 

modification, for specifying the basic function and queue at which the verification is to 
5 be performed, for selecting variables, parameters and values thereof, and for specifying 

the workflow consequences of an abnormal result. 

142. The method described in claim 141, further including the step of: 
providing a text box for use in creating a formula to be performed as the 

verification. 

143. The method described in claim 141, further including the step of: 
permitting the creation of the formula using words and mathematical operators. 

144. A workflow management system for a trustee handling a plurality of 
securitizations comprising: 

an electronic deal setup database which stores deal setup information, including 
information related to the structure of the securitizations; 
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a first data processing software module which receives asset level data 
transmitted by at least one asset manager and aggregates the asset level data; 
a workflow management software module; 

an first interface which receives the aggregated asset level data from the first 
data processing software module, and transmits the data electronically to the workflow 
management software module; 

a computer display generated under control of the workflow management 
software module, which displays status information concerning a particular 
securitization, provides prompts to a user as to work which is to be done with respect 
thereto, and which includes at least one active element from which the user may initiate 
actions with respect to the work; 

a second data processing software module which receives the aggregated asset 
level data, and responds to commands from the workflow management software module 
to perform computations related to payments due investors in the securitization; 

a second interface; and 

a third data processing software module which receives payment data produced 
by the second data processing software module through the second interface, and 
responds to commands from the workflow management software module to processes 
payments to the investors based on the payment data. 

145. The system described in claim 144, further including 
an electronic workflow status database which stores workflow status information for the 
securitizations. 
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146. The system described in claim 144, wherein the 

the computer display is based at least in part on recorded deal setup information in the 
electronic database. 

147. The system described in claim 145, wherein the 

the computer display is based at least in part on workflow status information recorded 
in the workflow status database. 

148. The system described in claim 145, wherein the 

workflow management software module is operative to update the workflow status 
database in response to actions initiated by users, and work completed. 

149. The system described in claim 144, wherein the electronic deal setup 
database stores information related to the performance of the trustee's duties in 
connection the securitizations. 

150. The system described in claim 144, further including a data handling 
device responsive to data and commands from the workflow management software 
module the data handling device being operative to electronically disseminate reports 
and other data compilations upon completion of the payment processing. 

151. The system described in claim 144, wherein the aggregated asset level data 
is in database form, and wherein the first interface maps the database structure of the 
aggregated asset level data for compatibility with the second data processing software 
module. 
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1 52. The system described in claim 151, wherein the payment data produced by 
the second data processing software module is in database form, and wherein the second 
interface maps the database structure of the payment data for compatibility with the third 
data processing software module. 

153. A workflow management system for handling a plurality of complex 
multiple step projects comprising: 

an electronic workflow management database which stores project setup 
information, including organizational information concerning the projects, and the 
5 sequence of workflow required to execute the project; 

a first data processing software module which receives raw data required to 
execute the project from at least one outside source, and processes the raw data; 
a workflow management software module; 

an first interface which receives the processed raw data from the first data 
1 0 processing software module, and transmits the data electronically to the workflow 
management software module; 

a computer display generated by the workflow management software module, 
which displays workflow status information concerning the projects, provides prompts 
to a user as to work which is to be done with respect thereto, and which includes at least 
1 5 one active element from which the user may initiate actions with respect to the work; 

a second data processing software module which receives the processed raw 
data, and responds to commands from the workflow management software module to 
perform computations using the processed raw data; 

a second interface; and 
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2 0 a third data processing software module which receives data through the second 

interface, and responds to commands from the workflow management software module 
to processes the received data. 

154. The system described in claim 153, further including a data handling 
device responsive to data and commands from the workflow management software 
module, the data handling device being operative to electronically disseminate reports 
and other data compilations. 

155. The system described in claim 153, wherein the processed raw data is in 
database form, and wherein the first interface maps the database structure of the 
processed raw data for compatibility with the second data processing software module. 

156. The system described in claim 155, wherein the data produced by the 
second data processing software module is in database form, and wherein the second 
interface maps the database structure of the data provided the second data processing 
software module for compatibility with the third data processing software module. 

157. The system described in claim 155, wherein the 

the computer display is based at least in part on recorded setup information in the 
electronic database. 

158. The system described in claim 153, wherein the 

workflow management software module is operative to update the workflow status 
database in response to actions initiated by users, and work completed. 
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ABSTRACT OF THE DISCLOSURE 

A computerized workflow management method and system to provide 
operational support for complex multi-step processes, having particular utility in 
supporting operations involving securitizations for which periodic valuation and 
5 distribution computations, disbursements and reporting must be set up and executed. 

The invention permits unification of manual operations and operations performed by 
legacy software, even if implemented with database structures different from the 
workflow management system, automated quality control, workflow status display and 
automatic updating of workflow status records. The method of workflow management 

1 0 involves creating an underlying database structure for recording the processing steps and 

other information required for each transaction, entering the necessary setup information 
by selection from lists of pre-stored information about processing functions, associated 
workflow events and milestones for the queues, mapping the data structures of the 
subsystem databases and the workflow management database to provide transparent 

1 5 interfacing and convenient manual entry of data were necessary, displaying for the user 

the workflow status of all transactions for which he or she is responsible, permitting 
menu driven initiation of required actions and automatically updating the database 
records for the universe of deals being managed by the system. 
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UNITED STATES OF AMERICA 
COMBINED DECLARATION AND POWER OF ATTORNEY FOR PATENT APPLICATION 



OFGS FILE NO. 
P/2167-221 



As a below named inventor, I hereby declare that; my residence, post office address and citizenship are as stated below next to my name; that I 
verily believe that I am the original, first and sole inventor (if only one name is listed below) or a joint inventor (if plural inventors are named) of the 
subject matter which is claimed and for which a patent is sought on the invention entitled: 

WORKFLOW MANAGEMENT SYSTEM AND METHOD 



the specification of which is attached hereto, unless the following box is checked: 

□ was filed on as United States patent Application Number or PCT International patent 

application number and was amended on (if any). 

I hereby state that I have reviewed and understand the contents of the above identified specification, including the claims, as amended by any 
amendment referred to above. 

I acknowledge the duty to disclose all information known to be material to patentability in accordance with Title 37, Code of Federal Regulations, 

§1.56. 

I hereby claim priority benefits under Tide 35, United States Code §119 of any foreign applications) for patent or inventor's certificate or United 
States provisional application(s) listed below and have also identified below any foreign application for patent or inventor's certificate having a filing 
date before that of the application on which priority is claimed: 



Prior Foreign or Provisional Application(s) 



COUNTRY 


APPLICATION NUMBER 


DATE OF FILING 

(day, month, year) 


PRIORITY CLAIMED 
UNDER 35 U.S.C. 119 


United States 


(SER. NO. NOT YET 
RECEIVED) 


7 April, 2000 


YES X NO 








YES NO 



I hereby claim the benefit under Tide 35, United States Code, §120 of any United States applications) listed below and, insofar as the subject matter 
of each of the claims of this application is not disclosed in the prior United States application in the manner provided by the first paragraph of Tide 35, 
United States Code, §112, I acknowledge the duty to disclose information which is material to patentability as defined m Tide 37, Code of Federal 
Regulations, §1.56 which became available between the filing date of the prior application and the national or PCT international filing date of this 
application. 



UNITED STATES 
APPLICATION NUMBER 


DATE OF FILING 

(day, month, year) 


STATUS 
(patented, pending, abandoned) 





















I hereby appoint customer no. 2352 OSTROLENK, FABER, GERB & SOFFEN, LLP, and the members of the firm, Samuel H. Weiner - Reg. 
No, 18,510; Jerome M. Berliner - Reg. No. 18,653; Robert C. Faber - Reg. No. 24,322; Edward A. Meilman - Reg. No. 24,735; Stanley H. 
Lieberstem - Reg. No. 22,400; Steven I. Weisburd - Reg. No. 27,409; Max Moskowitz - Reg. No. 30,576; Stephen A. Soffen - Reg. No. 31,063; 
James A. Finder - Reg. No. 30,173; William O. Gray, III - Reg. No. 30,944; Louis C. Dujmich - Reg. No. 30,625 and Douglas A. Miro - Reg. No. 
31,643, as attorneys with full power of substitution and revocation to prosecute this application, to transact all business in theTatent & Trademark 
Office connected therewith and to receive all correspondence. 

SEND CORRESPONDENCE TO: OSTROLENK, FABER, GERB & SOFFEN, LLP DIRECT TELEPHONE CALLS TO: 

1180 AVENUE OF THE AMERICAS (212) 382-0700 

NEW YORK, NEW YORK 10036-8403 
CUSTOMER NO. 2352 

I hereby declare that all statements made herein of my own knowledge are true and that all statements made on information and belief are believed to 
be true; and further that these statements were made with the knowledge that willful false statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the United States Code, and that such willful false statements may jeopardize the validity of 
the application or any patent issued thereon. 



FULL NAME OF SOLE OR FIRST INVENTOR 

Thomas MACKAY 


INVENTORS SIGNATURE S 


DATE / / 


RESIDENCE (City and either State or Foreign Country) ' S ^ f 

Massapequa, New York 


COUNTRY OF CITIZENSHIP 

United States 


POST OFFICE ADDRESS ^ 

126 Park Lane, Massapequa, N^w Jo^k 11758 


FULL NAME OF SECOND JOINT INVENTOR (IF ANY) 

Eileen MCCARTHY 


AnveAtor/s^i&nature 


DATE ifa/oo 


RESIDENCE (City and either State or Foreign Country) 

Larchmont, New York 


COUNTRY OF CITIZENSHIP 

United States 


POST OFFICE ADDRESS 

269 Murray Avenue, Larchmont, j$ew Yo/r,k 10538 / / 


FULL NAME OF THIRD JOINT INVENTOR (IF ANY) 

Eric RESCHKE 


IN^ENTQK^ SlA/TlM 1/ 




RESIDENCE (City and either State or Foreign Country) 

New York, New York 


COUNTRY OF CITIZENSHIP 

United States 


POST OFFICE ADDRESS 

652 Broadway, Apt. 8F 



□ CONTINUED ON PAGE 2 



United States Patent & Trademark Office 
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Application deficiencies were found during scanning: 



■ Page(s) 3. , 3 ; *nJ a< o f S p e c /Yy r: a -// were not present 

for scanning- (Document title) 



□ Page(s) of were not present 

for scanning. (Document title) 
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